plan de migración para aplicaciones considerado Java5 / java6 a Java 7?

Question

Actualmente estoy investigando si tiene sentido para retrasar algunos menores de Planificación de la refactorización trabajo y combinarla con la migración a Java 7, pero estoy un poco preocupado de que podría hacer más difícil rastrear las causas de algunos errores Si tanto el código y cambio de plataforma al mismo tiempo.

El beneficio de la medida podría ser la capacidad para limpiar y mejorar muchas cosas IO-relacionadas en la aplicación con NIO.2.

Tengo todas las fuentes necesarias de las aplicaciones y las bibliotecas relacionadas (si serían necesarios cambios). Teniendo en cuenta que Java 7 tiene sólo algunas pequeñas mejoras - después de la mayoría de las actualizaciones de la máquina virtual ya están en Java 6 y los cambios más grandes, como cierres o la motosierra se cancelan - debe ser lo suficientemente estable como para usarlo después de unos meses, a la derecha

Answer 1

Actualmente estoy investigando si tiene sentido para retrasar algunos menores planeado refactorización trabajo y combinarla con la migración a Java 7

Bueno, todavía hay mucha incertidumbre acerca de la programación Java 7, como se explicó recientemente por Mark Reinhold (Arquitecto Jefe de la Plataforma Grupo de Java en Oracle) en su blog y en la OpenJDK lista de correo :

Ha sido claro desde hace algún tiempo que la más reciente de JDK 7 calendario de desarrollo es, por decirlo suavemente, poco realista.

(...)

Nuestra mejor estimación actual es que podríamos completar, probar y estabilizar el trabajo planificado en el tiempo para un lanzamiento a mediados de 2012.

(...)

Nuestra estimación actual de este “Plan B” es que podríamos enviar una reducida JDK 7 a mediados de 2011 y JDK 8 en la segunda semestre de 2012.

Para resumir:

Plan A:     JDK 7 (as currently defined)                     Mid 2012
Plan B:     JDK 7 (minus Lambda, Jigsaw, and part of Coin)  Mid 2011
            JDK 8 (Lambda, Jigsaw, the rest of Coin, ++)    Late 2012

Así que en el mejor de los casos, Java 7 estará allí en un poco menos de un año y Java 8 (con los grandes cambios) en un poco más de dos años. Y en el peor de los casos, Java 7 estará allí en un poco menos de dos años.

El beneficio de la medida podría ser la capacidad para limpiar y mejorar muchas cosas IO-relacionadas en la aplicación con NIO.2.

En la parte posterior (NIO.2), necesitará Java 7. Sin embargo, para la parte anterior (limpieza), no hay ninguna OMI buenas razones para esperar si obtiene beneficios inmediatos, especialmente teniendo en cuenta la incertidumbre de la Java 7 horario.

Teniendo en cuenta que Java 7 tiene sólo algunas pequeñas mejoras - después de la mayoría de las actualizaciones de la máquina virtual ya están en Java 6 y los cambios más grandes, como cierres o la motosierra se cancelan - debe ser lo suficientemente estable como para usarlo después de unos meses, ¿verdad?

En primer lugar, incluso si la comunidad parece favorecer Plan B , no hay nada escrito en piedra para no basar una decisión al respecto. En segundo lugar, aunque Sol siempre ha tratado de maximizar la compatibilidad ascendente entre las versiones de Java y plataformas estables oferta, no puedo predecir el futuro :) Y aunque estoy bastante seguro, algunas empresas conservadoras probablemente esperar un poco (con independencia de la escenario elegido).

Referencias

• Re-pensar JDK 7 por Mark Reinhold (Arquitecto Jefe del Grupo de Plataforma Java en Oracle)
• Repensando JDK 7 por Mark Reinhold (Arquitecto Jefe de la plataforma Java Grupo en Oracle)