Backport Java 5/6 características para Java 1.4?

Question

Estamos atascados con Java2SE v1.4 hasta finales de 2010. Eso es realmente desagradable, pero no podemos evitarlo. ¿Qué opciones tenemos para usar algunas de las nuevas características ahora? Se me ocurren varias formas, como

• cambiando el bytecode, p. usando Retrotranslator o Retroweaver.

• backport de bibliotecas, p. Ej. Concurrent Backport, pero esto no ayuda con los genéricos.

• emulación de las características de Java 5, p. Colecciones verificadas, Varargs con métodos auxiliares, etc.

• cambiando el código fuente por precompilación, eliminando todas las 1.5 cosas antes de la compilación final, p. usando Declawer puede hacer esto.

Estoy muy interesado en la experiencia muy positiva con ella en entornos de producción utilizando Weblogic y esas cosas "real".

Answer 1

Gracias por sus respuestas. Aquí está el resumen de todas las respuestas relevantes y mi propia investigación.

Cambiar el código de bytes: La Retros
Esto se hace por el "retro"-tools: Retrotranslator, Retroweaver y JBossRetro. Retrotranslator parece ser el más maduro y activo de la herramienta. Estas herramientas escanean todas las clases y cambian el bytecode para eliminar las características de Java 5 y 6. Se admiten muchas características de Java5, algunas mediante el uso de bibliotecas de backport de terceros. Esta opción es la más popular y hay algunos comentarios positivos de los usuarios. Los experimentos mostraron que está funcionando como esperado. Vea una breve descripción en developerworks.

Pro: Puede desarrollar completamente en Java 5, construir módulos y todo tipo de JAR. Al final, simplemente transforma todas las clases a Java 1.4 y empaqueta su EAR. Esto se hace fácilmente con la integración Maven de Retrotranslator (org.codehaus.mojo:retrotranslator-maven-plugin).

Con: Los entornos conservadores no permiten que se implemente el bytecode modificado. El resultado del retroceso no es visible para ningún codificador y no puede aprobarse. El segundo problema es el miedo: puede haber algún problema críptico de producción y el retro-código es otro paso que podría culparse por eso. Los vendedores del servidor de aplicaciones pueden rechazar la ayuda debido a bytecode modificado. Entonces nadie quiere asumir la responsabilidad de usarlo en la producción. Como esto es más un problema policial que técnico , entonces no veo solución. Le ha ocurrido a nosotros, por lo que estaba buscando otras opciones :-(

Compilación Java5 a Java 1.4:. Jsr14
Hay una opción no compatible, javac -source 1.5 and -target jsr14 que compila la fuente Java5 a Java 1.4 válido el código de bytes más características como varargs o extendidas para el bucle son traducidas por el compilador de todos modos. los genéricos y anotaciones son despojados. enumeraciones no son compatibles y no sé sobre autoboxing, como los métodos valueOf se introdujeron en su mayoría en Java5.

con : Solo se traduce el código de bytes, el uso de la biblioteca no se modifica. Por lo tanto, debe tener cuidado de no t utilizar API específicas de Java5 (pero podría usar Backports). Además, tiene que compilar todos los módulos al mismo tiempo, porque para el tiempo de desarrollo, usted desea de manera viable código Java5 con información genérica y de anotación. Así que tienes que construir todo el proyecto desde cero para la producción de Java 1.4.

Cambiar la fuente de nuevo a Java 1.4: Declawer
Como respondió en un related question, hay Declawer, una extensión del compilador, que trabaja para los genéricos y varargs, pero no para la mejora de bucle o autoboxing. La fuente generada "es un poco cobarde, pero no está mal".

Pro: La fuente generada está disponible y puede ser revisada. En el peor de los casos, se pueden hacer arreglos en esta fuente. No hay "magia", porque la fuente es Java válida. Algunas personas incluso usan JAD (descompilador Java) para obtener la fuente Java 1.4 nuevamente. La salida de Jad legible es legible si compila con información de depuración y no utiliza clases internas.

Con: Similar a -target jsr14, necesita un paso adicional en la implementación. Los mismos problemas con las bibliotecas, también.

Cambio de Fuente de nuevo a Java 1.4: con la mano
Varias respuestas sugieren hacerlo a mano. Para un proceso de compilación automático y repetitivo, esto por supuesto no es útil, pero para cambios de una sola vez es razonable. Simplemente automatice lo que es posible. Tal vez consulte Antlr para crear una herramienta de conversión propia.

portado Bibliotecas:
El problema es, que también viene Java5 nuevas bibliotecas, que no están disponibles en los JRE mayores, ver related question. Afortunadamente hay varias bibliotecas de backported que le dan algunas funcionalidades de Java5, pero no pueden simular características de lenguaje, como los genéricos.

• Annotations, discutido en TSS
• Concurrent
• com.sun.net.httpserver (Java 6 a 5)
• Gif writing (Java 6 a 5)
• iniciar su propio proyecto backport ;-)
• Usted podría copiar las clases que necesita del JDK u otras bibliotecas, pero lo más probable es que estén relacionadas con otras clases.

Emulating Java5 cuenta en Java 1.4 código:
estaba pensando en algunas cosas que usted puede hacer para hacer su vida más fácil y aún así permanecer con Java 1.4. Las características más importantes son colecciones typesafe, He aquí algunas ideas:

• En lugar de utilizar los genéricos puede crear sus propios recipientes typesafe con alguna plantilla.
• Agregue un iterador seguro (que ya no es iterador).
• Agregue asList métodos que permiten 1,2,...,n argumentos y una matriz de ellos (para simular varargs).
• Los métodos para varargs (convertir 1,...,n argumentos en matrices) y valueOf se pueden poner en alguna clase de ayuda.

Answer 2

precompilación código fuente, despojando toda 1,5 cosas antes de la compilación final y despliegue. ¿Hay alguna herramienta que pueda hacer esto?

Sí. Se llaman Retrotranslator o Retroweaver. Además de Generics (que solo existe para el compilador de todos modos), no puedes simplemente "pelar 1.5 cosas". Los mensajes (y tal vez también algunas otras características) tienen que ser reemplazados por un código funcionalmente equivalente. Que es exactamente lo que hacen esas herramientas.

Answer 3

Puede codificar con JDK 1.5 características y JDK 1.4 en tiempo de compilación de destino. Vea las opciones de Javac disponibles. Sin embargo, la mayoría de las bibliotecas ahora están utilizando el código JDK 1.5, por lo que te quedarás con viejas librerías.

Answer 4

Vale la pena señalar que, si bien Java 1.4 ha sido EOL desde hace algún tiempo. Java 5.0 será EOL 8 de octubre de 2009. Si alguien te promete Java 5.0 para 2010, preguntaría por qué?

Answer 5

Para simular las anotaciones en Java 1.4 se puede utilizar http://xdoclet.sourceforge.net/xdoclet/index.html