Вперед совместимый процессор аннотаций Java 6 и SupportedSourceVersion - PullRequest
Новая
       82

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

22 голосов
/ 18 ноября 2011

Я пробую 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.Версия SourceVersion для Java 7 представляет RELEASE_7.

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

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

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

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

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

1 Ответ

13 голосов
/ 19 ноября 2011

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

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

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

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

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

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

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

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

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

...