JEP 119: javax.lang.model Implementation Backed by Core Reflection

Аннотация

Предоставить реализацию API javax.lang.model.*, основанную на core reflection, а не на javac. Иными словами, предоставить альтернативный API для доступа к рефлексивной информации о загруженных классах, которую даёт core reflection, и для её обработки.

Цели

Предоставить единый API для просмотра рефлексивной информации о типах и их членах, доступной во время компиляции и во время выполнения. Упростить эксперименты с языковыми возможностями, связанными с аннотациями.

Мотивация

У API core reflection есть ряд ограничений, заложенных в его дизайн. Подробнее см. Mirrors: Design Principles for Meta-level Facilities of Object-Oriented Programming Languages.

API javax.lang.model.* используется в javac для поддержки обработки аннотаций, однако API javax.lang.model.* не ограничивается моделированием структур Java во время компиляции.

Если бы существовала реализация javax.lang.model.* на основе core reflection, один и тот же код можно было бы использовать для анализа представлений типов во время компиляции и во время выполнения. Кроме того, поскольку javax.lang.model.* основан на интерфейсах, специализацию модели времени выполнения можно было бы использовать, чтобы гораздо проще экспериментировать с альтернативной семантикой аннотаций.

Например, некоторые участники предлагали изменить механизм аннотаций в языке так, чтобы он поддерживал стереотипирование, при котором применение одной аннотации логически разворачивалось бы в набор других аннотаций. Чтобы поддержать такую возможность во время выполнения через core reflection, потребовалось бы изменить как минимум одно из двух — javac или core reflection, — чтобы это разворачивание можно было выполнить. При подходящей реализации javax.lang.model.* для реализации стереотипирования или различных других вариантов семантики аннотаций можно было бы использовать небольшую специализацию метода getAnnotation, не изменяя ключевые части платформы.

Описание

Предполагаемый подход к реализации — предоставить набор фабричных методов, которые оборачивают объекты core reflection в адаптеры, реализующие соответствующую конструкцию javax.lang.model.*. Например, один метод, получив объект java.lang.reflect.Method, возвращал бы объект javax.lang.model.element.ExecutableElement с видом METHOD, соответствующим именем и т. д.; аналогично и для других языковых структур. Этот подход явно осуществим — реализация для проверки концепции прошла гладко, — но остаётся ряд открытых вопросов о дизайне и реализации:

• Должен ли API быть специфичным для JDK или войти в Java SE?

• Какую часть реализации следует открыть для специализации?

• Следует ли обновить стандартный javax.lang.model.*, чтобы он лучше поддерживал этот сценарий использования? Строго говоря, особые требования javax.lang.model.* применяются только тогда, когда API используется для обработки аннотаций.

• Следует ли предоставить специализацию API javax.lang.model.* для времени выполнения, дающую доступ к функциональности, специфичной для core reflection, например к вызову метода?

Тестирование

Основная сложность тестирования реализации javax.lang.model.* не в том, чтобы протестировать все методы как таковые, а в том, чтобы протестировать все методы на всех видах языковых структур. В основе API модели языка лежит структура моделируемого языка. Например, чтобы тщательно протестировать, скажем, метод getModifiers, нужно проверить каждый вид элементов, которые могут иметь модификаторы (типы, переменные, параметры и т. д.), с каждым набором модификаторов, допустимым для этого вида элементов, а это даже для такого простого поведения — десятки комбинаций.

Риски и допущения

Реализацию могут усложнить несоответствия между core reflection, который по своей сути даёт представление мира на уровне JVM, и чистой моделью языка. Одна из причин создать API, специализированный для core reflection, — разумно обрабатывать синтетические структуры, которые по определению находятся вне чистой модели языка.

Зависимости

Реализацию javax.lang.model.* упростили бы различные доработки API core reflection, часть которых уже внесена в сборки JDK 8. Например, новый суперкласс Executable для Method и Constructor облегчает совместное использование кода.

Если будет реализован доступ к именам параметров методов и конструкторов во время выполнения, этот проект станет естественным клиентом этих возможностей.

Влияние

• Совместимость: поведение javax.lang.model.* на основе core reflection и на основе javac будет различаться в ряде аспектов.

• Безопасность: будет использоваться механизм безопасности, лежащий в основе core reflection.

• TCK: если этот API будет поставляться как часть Java SE, некоторые тесты JCK для JSR 269, возможно, удастся адаптировать для тестирования этого API.