Backport Java 5/6 características de 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 funciones ya ahora? Puedo pensar en varias formas como

• cambiando el código de bytes, p. utilizando Retrotranslator o Retroweaver .

• backport de bibliotecas, p. Backport concurrente , pero esto no ayuda a los genéricos.

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

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

Estoy más interesado en una experiencia muy positiva en entornos de producción usando Weblogic y "real" cosas.

Answer 1

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

Cambio del bytecode: The Retros
Esto se realiza mediante " retro " -tools : Retrotranslator , Retroweaver y JBossRetro . El retrotranslator parece ser el más maduro y activa de ellos herramienta. Estas herramientas escanean todas las clases y cambian el código de bytes 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. Consulte una breve descripción general de 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 tu EAR. Esto se hace fácilmente con la integración de Retrotranslator's Maven ( org.codehaus.mojo: retrotranslator-maven-plugin ).

Con: Los entornos conservadores no permiten que se implemente el código de bytes modificado. El resultado del retro-paso no es visible para ningún codificador y no puede ser aprobado. El segundo problema es el miedo: puede haber algún problema críptico de producción y el retrocódigo es otro paso al que se puede culpar. Proveedores de servidores de aplicaciones podría rechazar la ayuda debido a un bytecode modificado. Entonces nadie quiere asumir la responsabilidad de usarlo en la producción. Como esto es más bien un aspecto policital que técnico problema, así que no veo solución. Nos ha sucedido, así que estaba buscando otras opciones :-(

Compilación de Java5 a Java 1.4: jsr14
Hay una opción no admitida, javac -source 1.5 y -target jsr14 que compila la fuente Java5 a un bytecode válido de Java 1.4. La mayoría de las características como De todos modos, el compilador traduce los varargs o el ciclo for extendido. Los genéricos y las anotaciones se eliminan. Las enumeraciones no son compatibles y no sé sobre autoboxing, ya que los métodos valueOf se introdujeron principalmente en Java5.

Con: solo se traduce el código de bytes, el uso de la biblioteca no cambia. Por lo tanto, debe tener cuidado de no usar API específicas de Java5 (pero podría usar Backports). Además, debe compilar todos los módulos al mismo tiempo, ya que para el tiempo de desarrollo probablemente desee código Java5 con información genérica y de anotación. Por lo tanto, debe construir todo el proyecto desde cero para la producción de Java 1.4.

Cambio de fuente de nuevo a Java 1.4: Declawer
Como se respondió en una pregunta relacionada , hay es Declawer , una extensión del compilador, que funciona para genéricos y varargs, pero no para mejorar para loop o autoboxing La fuente generada "es un poco funky, pero no está tan mal".

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

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

Cambiar el código fuente a Java 1.4: a mano
Varias respuestas sugirieron hacerlo a mano. Para un proceso de compilación automático y repetitivo, esto, por supuesto, no es útil, pero para cambios únicos es razonable. Simplemente automatice lo que sea posible. Tal vez mire Antlr para crear una herramienta de conversión propia.

Bibliotecas con respaldo:
El problema es que Java5 también incluye nuevas bibliotecas, que no están disponibles en JRE anteriores, consulte pregunta relacionada . Afortunadamente hay varios bibliotecas con respaldo que le brindan cierta funcionalidad de Java5, pero no pueden simular características del lenguaje, como los genéricos.

• Anotaciones , discutido en TSS
• Concurrente
• com.sun. net.httpserver (Java 6 a 5)
• Escritura GIF (Java 6 a 5)
• Comience su propio proyecto de backport ;-)
• Puede copiar las clases que necesita del JDK u otras bibliotecas, pero lo más probable es que estén relacionadas con otras clases.

Emulación de características Java5 en código Java 1.4:
Estaba pensando en algunas cosas que podrías hacer para hacerte la vida más fácil y seguir con Java 1.4. Las características más importantes son las colecciones de typesafe, Aquí hay algunas ideas:

• En lugar de usar genéricos, puede crear sus propios contenedores de tipo seguro con alguna plantilla.
• Agregue un Iterador seguro (que ya no es Iterator).
• Agregue métodos asList que permitan argumentos 1,2, ..., n y una matriz de ellos (para simular varargs).
• Los métodos para varargs (que convierten los argumentos 1, ..., n en matrices) y valueOf se pueden colocar en alguna clase auxiliar.

Answer 2

  

precompilación de código fuente, eliminación   todas las 1.5 cosas antes de la compilación final   y despliegue. ¿Hay alguna herramienta?   ¿Qué puede hacer esto?

Sí. Se llaman Retrotranslator o Retroweaver. Aparte de los genéricos (que de todos modos solo existen por el bien del compilador), no puede simplemente "quitar 1.5 cosas". Las enumeraciones (y quizás también algunas otras características) deben reemplazarse con un código funcionalmente equivalente. Que es exactamente lo que hacen esas herramientas.

Answer 3

Puede codificar con las funciones de JDK 1.5 y apuntar a JDK 1.4 en tiempo de compilación. Ver las opciones Javac disponibles. Sin embargo, la mayoría de las bibliotecas ahora utilizan el código JDK 1.5, por lo que se quedará atascado con libs antiguas.

Answer 4

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

Answer 5

Para simular anotaciones en Java 1.4, puede usar http://xdoclet.sourceforge.net/ xdoclet / index.html