JEP 190: Pluggable Static Analyzers
Подключаемые статические анализаторы
| Authors | Eric 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, и в нём нет некоторых возможностей, критически важных для определённых видов анализа.