¿Cómo justificar la migración de Java 6 a Java 7?

28

Estábamos migrando de Java 6 a Java 7 . El proyecto está retrasado y corre el riesgo de caerse, en cuyo caso continuará utilizando Java 6.

¿Cuáles son las mejoras específicas en Java 7 con las que podríamos volver a nuestro administrador y convencerlo de que es importante usar JDK 7? Buscando correcciones de errores que podría resaltar en Oracle Java 7 (con respecto a Java 6). Las correcciones en seguridad, rendimiento, Java 2D / impresión, etc. serán más vendibles en mi caso. Las correcciones del compilador, por ejemplo, no serán de mucha utilidad.

[Estoy visitando muchos sitios como la guía de adopción de Oracle , la base de datos de errores, preguntas sobre Stack Overflow].

Actualización: gracias por las respuestas. Reprogramamos la actualización para la próxima versión. Lo más cerca que estuvimos fue seguridad. Aceptando la respuesta más votada.

java migration Jayan
fuente
55
Tienes suerte. A partir de las preguntas que aún aparecen regularmente en Stack Overflow , algunas personas todavía están atrapadas con Java 1.4 (¡una plataforma que tiene 11 años!).
Joachim Sauer
3
¿Por qué está realizando la actualización ahora si aún no conoce algunas de las características que necesita en 7? Tal vez está perdiendo el tiempo y debería pensar un poco más sobre si debe justificarlo en lugar de cómo debe justificarlo.
Bryan Oakley
1
¿Soy solo yo o el título está al revés?
Radu Murzea
1
La pregunta más importante es: ¿Por qué le cuesta tanto actualizar? Pude actualizar un proyecto de un millón de loc en una semana a Java 7. Creo que la respuesta a sus problemas es analizar por qué le está costando tanto realizar la actualización.
Andrew T Finnell
2
@ Andrew Finnell: Lo siento. No pensé que fuera tan relevante. El portado real se completó en menos de una semana. Principalmente debido a la propiedad de Sun que utilizamos. Era un código afectado por la compatibilidad específica de la función que el número real de líneas de código (4 millones aprox.). La demora causada se debió a varios factores, como el soporte de herramientas: por ejemplo, cobertura de código con cobertura 2.0. Es solo estabilizador. Otra herramienta era Rational Functional Tester, que requería una actualización (elegimos no hacerlo). Puede que escriba una nota sobre los factores generales que afectaron el esfuerzo ...
Jayan

Respuestas:

44

Java 6 llegó a EOL en febrero de este año y ya no recibirá actualizaciones públicas (incluida la seguridad) a menos que compre un soporte empresarial muy costoso.

Esa debería ser toda la razón necesaria.

Además, la evidencia abrumadora sugiere que la compatibilidad con versiones anteriores de los tiempos de ejecución de Java es excelente. Lo más probable es que solo tenga que reemplazar las instalaciones de Java 6 con Java 7 y todas las aplicaciones continuarán funcionando sin ningún problema. Por supuesto, esto no está garantizado y se recomiendan pruebas exhaustivas para confirmar que efectivamente no habrá problemas.

Michael Borgwardt
fuente
2
Esa debería ser una respuesta aceptada. El razonamiento basado en EOL ha demostrado funcionar mejor para mí siempre que haya una necesidad de justificar actualizaciones de productos particulares, particularmente Java. Para completar la justificación, también agregaría la nota sobre compatibilidad binaria hacia atrás (preferiblemente respaldada con alguna declaración oficial de Oracle) y una nota sobre la necesidad de probar la actualización (por ejemplo, algunas dependencias inesperadas de referencias codificadas a la versión " 6 "en configuraciones de aplicación)
mosquito
1
es básicamente la única razón por la cual la mayoría de las compañías actualizarán.
Jwenting
Michael, ¿tendría sentido agregar notas que mencioné ( aclaraciones sobre compatibilidad y pruebas de humo ) en tu respuesta? en aras de la integridad, por así decirlo
mosquito
1
@gnat: hecho, aunque dudo que las personas que están en contra de la migración necesiten que se les informe sobre la necesidad de realizar pruebas y más que solo pruebas de humo. Definitivamente , a veces hay serias incompatibilidades.
Michael Borgwardt
@MichaelBorgwardt bien, contar eso es algo complicado y tiene más que ver con ser convincente que técnicamente correcto. Por mi parte, aprendí una forma bastante difícil de decir cosas como esa de manera explícita y clara cuando hay personas "en contra del cambio". Esto les envía una señal de "escuchamos y compartimos sus inquietudes, y también nos preocupamos", los hace sentir valorados (en lugar de ignorados) ... y finalmente lleva a una aprobación más fácil del cambio :)
mosquito
29

En general, hay una serie de cambios bastante amplios para facilitar las cosas al programador. Es posible que su gerente no se preocupe demasiado por esas cosas, pero hacer que los programadores pasen menos tiempo pensando en el código repetitivo y, por lo tanto, tengan más tiempo para pensar sobre el objetivo real de lo que están implementando, debería aumentar la eficiencia, disminuir los errores, etc. lo cual puede ser un argumento muy poderoso. Oracle tiene una lista bastante extensa de cambios , pero es bastante larga, por lo que resumiré tanto como sea posible.

Las características del lenguaje incluyen:

  • Menos repetitivo en genéricos. El código Map<String, String> myMap = new HashMap<String, String>();se puede reducir a Map<String, String> myMap = new HashMap<>(). El compilador puede inferir los tipos genéricos necesarios en el lado derecho desde la izquierda, por lo que su código se vuelve un poco más corto y más rápido de leer.
  • Las cadenas funcionan ahora en sentencias de interruptor , utilizando la semántica del .equals()método en lugar de ==.
  • Gestión automática de recursos utilizando try-with-resources. Esto hace que el código sea más limpio, pero también tiene una ventaja sobre el código antiguo de prueba / finalmente basado. Si se lanza una excepción en la declaración de prueba, y luego se lanza otra al cerrar, el código que usa las declaraciones tradicionales de prueba / finalmente perderá por completo la excepción original, y solo pasará la que se lanzó en el bloque finalmente. En una declaración de prueba con recursos, el tiempo de ejecución suprimirá la excepción que arrojaron las llamadas close () y burbujeará la excepción original en la pila, bajo el supuesto de que esta excepción original es la que causó todos los problemas en el primer lugar. Además, en lugar de abandonar la otra excepción al recolector de basura, esta supresión permite que se recuperen las excepciones lanzadas de cerca usando Throwable.getSuppressed.
  • Los literales numéricos pueden hacerse más fáciles de leer. Todos los literales numéricos permiten guiones bajos , por lo que cosas como int n = 1000000000se pueden convertir en mucho más legibles int n = 1_000_000_000, lo que es mucho más fácil de analizar como mil millones y más difícil de escribir incorrectamente sin darse cuenta. Además, los literales binarios están permitidos en el formulario 0b10110101, lo que hace que el código que funciona con campos de bits sea un poco más agradable de leer.
  • Se puede manejar múltiples tipos de excepción en la misma instrucción catch , reduciendo la duplicación de código y potencialmente facilitando la refactorización posterior.

Cada uno de estos cambios es algo que a su gerente podría no importarle directamente, pero hacen que sea un poco más fácil escribir el código correcto sin tanto esfuerzo y pensamiento, liberando su mente para concentrarse un poco más en la lógica real que está intentando para implementar, y también hacen que sea un poco más fácil leer el código más tarde, lo que hace que la depuración sea un poco más rápida.

En el lado de la API, también se han producido varias actualizaciones de la API:

  • En cuanto a la seguridad , se han agregado / desaprobado varios métodos de encriptación, a medida que la criptografía avanza.
  • El archivo IO ha sido cambiado ( aunque este podría ser un mejor enlace ) agregando una mejor abstracción en varios lugares. No me he sumergido personalmente en las nuevas cosas de IO, pero parece una revisión muy útil, lo que hace que sea mucho más fácil trabajar con el sistema de archivos sin tanto dolor.
  • El soporte Unicode es hasta Unicode 6.0, junto con una serie de otras mejoras de internacionalización.
  • Java2D , que mencionó en su pregunta, se ha mejorado. Mejor soporte de fuentes Linux, mejor renderizado X11 en máquinas modernas y manejo de scripts tibetanos.
Billy Mailman
fuente
1
Selección de nit: De hecho, el interruptor de cadena funciona "como si estuviera usando el String.equalsmétodo" (del documento al que se vinculó). En realidad, el compilador es libre de optimizar para que String.equalsno se use ... siempre que el efecto neto sea el mismo. (Y, esperaría que use String.hashcodemás de un cierto número de casos de cambio).
Stephen C
Suficientemente cierto. Sin embargo, la mayoría de los compiladores pueden hacer un montón de optimizaciones que no cambian la semántica, por lo que a menudo es redundante señalar pequeñas cosas como esa; Solo mencioné específicamente .equals () para que sea explícito que el caso no se ignora. Sin embargo, he actualizado un poco la redacción.
Billy Mailman
Los interruptores de cadena no son una práctica recomendada ya que se cambia a un dominio independiente. Activar Enums es un término medio típico aquí, ya que puede tener una representación similar a String, pero con un significado semántico. Ah y +1 para la respuesta completa BTW.
Martijn Verburg
¿Cuáles son las ventajas de usar cadenas en una instrucción switch en lugar de constantes enteras?
Giorgio
3
La única razón comercial entre ellos puede ser la mejora de la seguridad. Las sutilezas técnicas son discutibles y absolutamente irrelevantes para la gente de negocios.
Jwenting
8

try-with-resources es una característica que vale la pena actualizar a Java 7, todo por sí mismo. Las fugas de recursos / fugas de memoria son un gran riesgo en el desarrollo de Java y TWR reduce significativamente ese riesgo.

Agregaré que la nueva abstracción de archivos NIO.2 y las capacidades asincrónicas también valen la pena si su aplicación tiene características de E / S de archivos / redes.

Martijn Verburg
fuente
También están reduciendo la cantidad de PermGen que se necesita y, en su lugar, utilizando el Heap o la memoria nativa, no estoy seguro de dónde se almacenará ahora. Esto significa que con Java 8 no necesitará establecer dos parámetros de memoria máxima.
Andrew T Finnell
¿No es probar con recursos lo mismo que probar por fin pero con menos repetitivo?
jhewlett
1
Creo que la idea es que menos repetitivo significa que es más fácil acertar.
MatrixFrog
1
Menos placa de caldera y correctores de cierre correctos. Descubrieron que dentro del OpenJDK lo estaban haciendo mal manualmente aproximadamente 2/3 de las veces ... Sospecho que hay otros porcentajes altos de esto en otros corpus de código.
Martijn Verburg
6

Puede haber una razón para que no cambie a Java 7: Si usted tiene que utilizar la VM de Oracle y su software o bien se ejecuta en el hardware incorporado o se distribuirá con hardware integrado: Oracle cambió su licencia de JRE para que quede sin licencia si está por encima se cumplen las condiciones; necesitará comprar una licencia incorporada de Java SE. Consulte ¿Qué significa "sistema de propósito general" para Java SE Embedded?

Restablece a Mónica - M. Schröder
fuente