Consideraciones sobre qué versión de Java ejecutar en producción


14

Algunas personas utilizan la tecnología más avanzada: actualizan el día en que algo se actualiza. En producción, esto no es tan apropiado.

Investigar si la versión actual (Java 7) está lista para la producción produce una cantidad significativa de material antiguo que podría no ser correcto (en el momento de escribir este artículo, Java 7 ha estado fuera durante un año y medio, lo que parece mucho tiempo) .

¿Qué consideraciones debo hacer para determinar si es apropiado actualizar el entorno de producción a una versión posterior de Java?


Incluso si lo fuera, cualquier biblioteca / complemento de terceros que se use (si corresponde) en dicha aplicación también necesitaría estar bien con Java 7 (negocio riesgoso).
arin

2
Si. El único problema con el que me he encontrado es que no pude instalar Java 7 en Red Hat Enterprise Linux 4, pero ese sistema operativo está obsoleto. Lo he estado usando en producción en otros lugares durante aproximadamente 6 meses sin ningún problema.
GlenPeterson

@arin: no con Java, no realmente. Tiende a ser ridículamente compatible con versiones anteriores.
Michael Borgwardt

@MichaelBorgwardt en teoría, estoy de acuerdo con usted, pero en el entorno de prueba, he visto que las bibliotecas de terceros causan fallas o comportamientos erráticos en nuestro código de prueba, incluso después de actualizar a una actualización de versión pequeña.
arin

@arin: claro, puede suceder. Pero en mi experiencia es tan raro que hay menos razones para tener miedo de actualizar Java que de cambiar casi cualquier otra cosa (especialmente el propio código).
Michael Borgwardt

Respuestas:


11

La primera pregunta es "¿La versión de Java es compatible con la máquina?" Si bien la actualización del JRE es una cosa, puede ser que el sistema operativo subyacente no sea compatible con la nueva versión de Java (certificaciones y contratos de soporte compatibles y similares que a muchos entornos empresariales les gusta tener).

Muchos entornos de producción de Java realmente se ejecutan sobre un servidor de aplicaciones . Esta sería la próxima consideración. La comparación de Wikipedia de los servidores de aplicaciones Java EE muestra qué versión de Java EE es compatible. Esto se puede ver en la descripción general de compatibilidad JavaEE de Oracle . La configuración probada para JBoss Enterprise Application Platform 6 está en contra de Java SE 6.0 actualización 6u30. La actualización Java SE 6.0 6u30 también es la configuración probada para JBoss Application Server 7.1.0 Final . Estos pueden funcionar en Java 7, pero no son configuraciones probadas.

Al expandirse en el servidor de aplicaciones, hay herramientas de análisis de código en vivo que se utilizan para depurar después del hecho. Depurador omnisciente (véase también) y Dynatrace son dos ejemplos de esto. Estas aplicaciones funcionan instrumentando (modificando) el código de bytes en vivo de Java Running para informar de ello. Como estas aplicaciones funcionan modificando el código de bytes, si el código de bytes cambia de una manera con la que no son capaces de trabajar (como en un nuevo JRE), no funcionarán.

Lo siguiente en la línea son los marcos . Un ejemplo de esto es JAXB que viene con Java y Spring que lo usa. El cambio a Java 7 actualizó JAXB que generó código que era incompatible con algunos marcos (lo que requiere que se actualicen y sus dependencias tendrían que actualizarse ...).

Las herramientas de compilación son las siguientes en la lista. Debería asegurarse de que el entorno de compilación esté utilizando la versión adecuada de Java. Escribir código para Java 7 pero no actualizar la versión que usa Maven o Ant causaría problemas. Hay momentos en que las herramientas de compilación están fuertemente vinculadas a una versión con complementos particulares.

Herramientas de prueba . Es posible que cosas como PMD, findbugs y checkstyle no reconozcan nuevas estructuras en una nueva versión de Java; esto puede confundirse mucho con las declaraciones de cambio de cadena o capturas compuestas. Las herramientas que entran en la instrumentación, como la cobertura del código, pueden no funcionar en la nueva JVM. En el contexto de Java 7, Cobertura y Emma no se han actualizado al nuevo JRE (nuevamente, estas aplicaciones modifican el código de bytes para ver qué código se ejecuta y cuál no) (ver bibliotecas de cobertura de código fuente abierto para jdk7 ). Esto podría requerir un cambio en los scripts de compilación para cambiar de uno a otro.

Luego está el IDE . Sería necesario actualizar el IDE a una versión que conozca las nuevas estructuras en el lenguaje. El anuncio de soporte de Eclipse para Java 7 muestra estos problemas.

Por último y ciertamente no menos importante es el desarrollador . Depende del desarrollador escribir el nuevo código y tener en cuenta cómo se puede reestructurar el código. Pasando de Java 1.4 a 1.5, se introdujeron plantillas y anotaciones y los desarrolladores tardaron en adoptar la mentalidad de las nuevas estructuras disponibles. Del mismo modo, las colecciones vuelven a funcionar en 1.2 y alejan a los desarrolladores del uso de HashTable y Vector. La actualización de la versión debe ir acompañada de cierta capacitación en las nuevas estructuras lingüísticas.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.