Вперед совместимый процессор аннотации Java 6 и SupportedSourceVersion

Я тестирую Java 7 для одного проекта и получаю предупреждения от обработчиков аннотаций (Bindgen и Hibernate JPA modelgen) такого типа:

warning: Supported source version 'RELEASE_6' from annotation processor 'org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor' less than -source '1.7'

Это вызвано аннотацией @SupportedSourceVersion(SourceVersion.RELEASE_6) на классах процессоров аннотаций. Поскольку они скомпилированы с Java 6, для них доступно самое высокое значение SourceVersion RELEASE_6. Версия Java 7 SourceVersion представляет RELEASE_7.

Мои вопросы: Как процессоры обработки аннотаций должны работать с передовой совместимостью? Должны ли быть отдельные двоичные версии jdk6 и jdk7? Разве я не понимаю здесь ничего другого?

Я нашел только следующую информацию относительно этой проблемы:

Отчет об ошибке Querdydsl, который использовал

@Override
public SourceVersion getSupportedSourceVersion() {
    return SourceVersion.latest();
}

блог Oracle, в котором комментатор рекомендует поддерживать последнюю версию исходного кода

Ответ 1

Перспективная совместимость обрабатывается путем правильной обработки неизвестных языковых конструкций, например, путем реализации ElementVisitor.visitUnknown.

В упомянутом блоге Oracle есть еще одна запись, в которой предлагаются две политики в отношении передовой совместимости:

Запишите процессор только для работы с текущей версией языка.

Напишите процессору, чтобы он справился с неизвестными будущими конструкциями.

Второй выполняется путем возврата SourceVersion.latest(), как уже было опубликовано в вопросе.

Я думаю, что это нормально делать в большинстве случаев, когда вы уверены, что дополнительные языковые элементы ничего не сломают. Конечно, вы не должны просто предполагать, что все будет хорошо даже с более новыми версиями, вы тоже должны его протестировать.

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

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

Предположим, что у вас есть процессор, который проверяет каждый элемент, который он может найти, и анализирует структуру кода для создания графика из него. У вас могут возникнуть проблемы с более новыми версиями. Вы можете каким-то образом обрабатывать неизвестные языковые конструкции (например, добавляя к графику неизвестный node), но делайте это только в том случае, если это имеет смысл - и если это того стоит. Если бы процессор просто не был бы полезен больше, если он столкнулся с чем-то неизвестным, он должен, вероятно, придерживаться определенной версии java.

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