que - Procesador de anotaciones Java 6 compatible con versiones posteriores y SupportedSourceVersion

notacion en java

Question

Estoy probando Java 7 para un proyecto y obteniendo advertencias de los procesadores de anotación (Bindgen y Hibernate JPA modelgen) de este tipo:

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

Esto se debe a la @SupportedSourceVersion(SourceVersion.RELEASE_6) en las clases del procesador de anotaciones. Dado que están compilados con Java 6, el valor más alto de SourceVersion disponible para ellos es RELEASE_6 . La versión Java 7 de SourceVersion presenta RELEASE_7 .

Mis preguntas: ¿Cómo se supone que los procesadores de anotaciones deben manejar la compatibilidad hacia adelante? ¿Tendrá que haber versiones binarias separadas de jdk6 y jdk7? ¿No estoy entendiendo algo más aquí?

Solo encontré la siguiente información con respecto a esta preocupación:

Informe de error Querdydsl que utiliza

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

Blog de Oracle en el que un comentarista recomienda apoyar la última versión de origen.

Answer 1

La compatibilidad hacia adelante se maneja procesando las construcciones de lenguaje desconocido de manera apropiada, por ejemplo, implementando ElementVisitor.visitUnknown .

Hay otra entrada en el mencionado blog de Oracle , que sugiere dos políticas con respecto a la compatibilidad hacia adelante:

• Escriba el procesador para trabajar solo con la versión actual del idioma.
• Escriba el procesador para hacer frente a construcciones futuras desconocidas.

El segundo se realiza devolviendo SourceVersion.latest() como ya se publicó en la pregunta.

Creo que está bien hacer esto en la mayoría de los casos, cuando está seguro de que los elementos de idioma adicionales no romperán nada. Por supuesto, no debe asumir que todo estará bien, incluso con las versiones más recientes, también debe probarlo.

Ok, creo que procesar construcciones de lenguaje desconocido suena un poco vago, así que aquí hay algunos ejemplos.

Se supone que tiene un procesador que verifica un tipo personalizado de anotaciones en construcciones de lenguaje conocidas (anotaciones en una clase, por ejemplo) y crea una documentación simple de lo que ha encontrado. Probablemente sea seguro asumir que también funcionará en versiones más nuevas. Restringirlo a una versión en particular no sería una buena decisión en mi opinión.

Se supone que tiene un procesador que verifica cada elemento que puede encontrar y analiza la estructura del código para generar un gráfico a partir de él. Puede tener problemas con las versiones más nuevas. Es posible que pueda manejar construcciones de lenguaje desconocido de alguna manera (como al agregar un nodo desconocido al gráfico), pero solo haga esto si tiene sentido, y si vale la pena. Si el procesador simplemente ya no sería útil cuando se enfrentara a algo desconocido, probablemente debería atenerse a una versión java en particular.

Independientemente de la política utilizada, la mejor manera en mi opinión sería monitorear los próximos cambios en el idioma y actualizar el procesador en consecuencia. En Java 7, por ejemplo, la moneda del proyecto introdujo algunas características nuevas de lenguaje, que probablemente ni siquiera sean visibles para un procesador. Java 8, por otro lado, tiene nuevas construcciones que afectarán el procesamiento, por ejemplo, anotaciones de tipo . Sin embargo, las nuevas características de lenguaje no ocurren tan a menudo, por lo que es probable que ni siquiera necesite cambiar nada durante mucho tiempo.