¿Existe un fragmento de programa Java que pueda compilarse con un compilador Java 5 en JRE 6 pero no en un compilador Java 6?

Question

Quiero tener un archivo fuente que pueda compilarse con javac/ecj establecido en Java 5 pero no en Java 6 (incluso si el tiempo de ejecución Java subyacente es Java 6).

Esto es para asegurarse de que el nivel del compilador está configurado correctamente en Eclipse 3.5 ejecutándose con Java 6 instalado, pero donde el resultado debe ejecutarse en una instalación de Java 5.

Para java 1.4 Podría usar "enum" como nombre de variable (que falla en Java 5 y posterior) pero no puedo encontrar un enfoque similar para Java 5 versus 6 (y posterior).

Sugerencias?

Answer 1

No hay nada en el lenguaje Java que fue removido entre JDK5 y 6. Lo único que se añadió, como se ha dicho, se estaba permitida en los métodos de la interfaz de la anotación @Override - No hay palabras clave. Por lo tanto, temo que te quedan muchas diferencias en las bibliotecas como la única causa de los cambios.

Estas existen, incluso en la API central; en un ataque inusual de juerga de compatibilidad con versiones anteriores, cambiaron la firma de algunos métodos en la interfaz ExecutorService. Esto se debió a que las firmas genéricas de los métodos eran demasiado restrictivas. Esta fue una biblioteca pura cambio (aunque, siendo parte de java.util, una bonita biblioteca central ); nada que ver con ninguna modificación de nivel de idioma.

Por ejemplo, from JDK5:

<T> T invokeAny(Collection<Callable<T>> tasks) 

to JDK6:

<T> T invokeAny(Collection<? extends Callable<T>> tasks) 

Esto significa que cualquier programa que contenía código implementación de esta interfaz en JDK5, no habría compilado con JDK6. Un fragmento es fácil de crear; simplemente deje que su IDE cree una implementación vacía de la interfaz JDK5 y luego contruya contra JDK6.

Nota: que se añadió el comodín porque la versión anterior no habría aceptado un parámetro como List<MyCallable<String>> (es decir, la colección se escribe por alguna subclase de opción de rescate), mientras que la versión posterior lo hace.

Answer 2

Dado que JVMDI se eliminó y JVMPI se deshabilitó en Java SE 6 (según J2SE 6.0 release note), puede agregar un código con esa API: no se compilará con J2SE 6.0, solo 5.0. (como se ilustra en this thread)

Answer 3

No es una respuesta a su pregunta, sino una alternativa a su enfoque: ¿no sería posible usar un segundo constructor, basado en ant o maven, que utilice bajo demanda para crear el aplicación o biblioteca? Esta compilación usaría un SDK Java 5 externo real y, por lo tanto, garantizaría que la aplicación/biblioteca se ejecute en un entorno Java5.