openjdk.ruOpenJDK на русском

JEP 190: Pluggable Static Analyzers

Подключаемые статические анализаторы

AuthorsEric McCorkle, Brian Goetz
ОтветственныйJan Lahoda
ТипFeature
ОбластьJDK
СтатусDraft
Компонентtools / javac
Обсуждениеcompiler dash dev at openjdk dot java dot net
ТрудоёмкостьM
ДлительностьM
ОдобренBrian Goetz
Создан2013/06/13 20:00
Обновлён2015/05/04 18:53
Задача8046180

Аннотация

Исследовать варианты проектирования фреймворка подключаемых статических анализаторов типов для javac. Этот фреймворк вместе с аннотациями типов из JSR 308 (JEP 104) позволит пользователям определять расширения, выполняющие произвольный статический анализ во время компиляции. Конечная цель этой работы — предоставить общий фреймворк для реализации инструментов анализа кода; однако цель данного этапа — исследовать варианты проектирования и накопить знания и опыт.

Цели

Это исследовательский JEP. Единственная цель этого JEP — исследовать варианты проектирования в достаточной мере, чтобы можно было предложить JEP для реализации возможности (или рекомендовать не заниматься этой возможностью).

Цели можно сформулировать следующим образом:

  • Собрать и проанализировать требования к статическим анализаторам и к фреймворку для их поддержки.

  • Реализовать несколько статических анализаторов, чтобы доказать осуществимость и чтобы они служили примером.

Что не является целью

  • Это не фреймворк для преобразований или оптимизаций; статические анализаторы не должны изменять программу.

  • В рамках этой работы нам не следует самим реализовывать большое количество статических анализаторов сверх того, что необходимо, чтобы оценить и понять инженерные вопросы, предоставить небольшой набор примеров и дать сообществу инструменты для переноса существующих реализаций анализа на этот фреймворк.

  • Цель этого JEP не состоит в создании реализации или спецификации, готовой к промышленному использованию.

Критерии успеха

Этот исследовательский JEP будет считаться успешным, если в его результате появится проект, который мы захотим развить в JEP для реализации возможности, ИЛИ уверенность в том, что мы не хотим продолжать работу над этой возможностью.

Мотивация

Эта работа приносит пользу экосистеме языка Java по нескольким направлениям. Во-первых, она даёт основу, на которой мы можем построить инструменты статического анализа для повышения качества JDK. Кроме того, она, вероятно, вызовет новый интерес к расширениям системы типов Java как в индустрии, так и в академических исследованиях. Но самое важное — она позволит командам разработчиков настраивать и собирать инструменты анализа, которые эффективнее обеспечивают соблюдение их стандартов кодирования и эффективнее обнаруживают ошибки, типичные для их конкретных приложений.

Простой пример того, что можно сделать с помощью предлагаемого фреймворка, — расширение базовой системы типов, которое выдаёт предупреждения для набора антипаттернов, заведомо создающих проблемы, таких как изменяемые статические поля (вероятный риск безопасности), сравнение ссылок (вероятная ошибка) и переопределение equals без переопределения hashCode (проблема производительности).

Однако возможные применения гораздо шире. Такие инструменты, как FindBugs, lint и им подобные, можно было бы заново реализовать в виде подключаемых анализаторов и использовать как часть цикла сборки. Предлагаемый фреймворк вместе с аннотациями типов также открывает путь к более мощным методам обнаружения ошибок и верификации, таким как проверка моделей (model checking) и формальные спецификации.

Предлагаемый фреймворк также можно адаптировать для аналогичной работы с байт-кодом, что даст многие из тех же преимуществ.

Описание

Пользователи должны иметь возможность определять конфигурацию компиляции, которая состоит из набора выбранных проверок и данных конфигурации для этих проверок. (Например, пользователь может захотеть настроить сопоставление с уровнями диагностики, чтобы одни проверки становились предупреждениями, другие — ошибками и т. д.)

Плагин проверки должен поддерживать мелкогранулярную упаковку, а проверки должны иметь возможность запрашивать доступ к исходному коду, байт-коду, дереву и данным classpath, а также выдавать диагностическую информацию, которая объединяется с диагностическим выводом компиляции. Сопровождающим существующих инструментов проверки (таких как FindBugs) должно быть легко переупаковать свои проверки по отдельности в виде плагинов.

Альтернативы

Существует несколько фреймворков, созданных в ходе академической работы. Многие из них не являются продуктами, готовыми к промышленному использованию, и они не разрабатывались для чистой интеграции с javac. Существуют также готовые к промышленному использованию автономные инструменты (прежде всего FindBugs), которые применяются в коммерческой разработке программного обеспечения. Однако сейчас они отделены от цепочки инструментов javac. Поэтому их приходится запускать как отдельные инструменты, встраивать их в систему сборки и тестирования непросто, и нет простого способа выбрать отдельные возможности из нескольких разных инструментов.

ASM — это фреймворк для анализа и переписывания байт-кода. Однако он не умеет анализировать исходный код на Java, и в нём нет некоторых возможностей, критически важных для определённых видов анализа.