instalar - Razones y ventajas para actualizar a Java 6 para un decisor no técnico(en el cliente)
java offline (11)
Me gustaría actualizar de Java 5 a Java 6. Todos conocemos las ventajas técnicas y los beneficios, pero:
Tengo el problema de que un cliente importante se niega a actualizar de java 5 a java 6 por "los riesgos" y "no / muy pocos beneficios para nosotros" (sector bancario).
¿Qué se puede responder a un decisor no técnico en el cliente qué beneficios obtendrá de una actualización, o de lo contrario qué problemas / consecuencias pueden surgir si se queda con Java 5?
No es un producto de "fuego y olvídate", se amplía de manera activa con nuevas funcionalidades / características; el desarrollo está y continuará constantemente; el equipo de desarrollo se beneficiaría definitivamente de las características / herramientas de jdk 6.
EDITAR: La EOL alcanzada de Java 5 es un punto válido, pero no convence al cliente porque está utilizando el IBM JRE / JDK 5 , que parece que todavía no ha alcanzado su fin de vida . Y, además de eso, el cliente afirmó: "Java 5 funciona bien durante años y es poco probable que surjan problemas nuevos e invisibles".
Actualizamos de 1.4 a 1.6 el año pasado. Ha sido una gran ayuda para el desarrollo, pero no sin inconvenientes. Si bien esta no era nuestra motivación, hoy estamos obligados a "mantenernos al día" con PCI (requisitos de manejo de tarjetas de crédito). Su aplicación puede estar funcionando sin problemas, pero estoy seguro de que Java 1.5 tiene algunos agujeros de seguridad que se han solucionado desde 1.6.
Con el tiempo, el cliente tendrá que actualizarse cada vez más debido a cosas como:
- Java 5 no es compatible con algún hardware nuevo o plataforma de sistema operativo,
- bajo rendimiento relativo a las versiones más nuevas de Java,
- mayores costos de codificación y prueba en relación con las versiones más nuevas de Java; por ejemplo, debido al "clunkiness" de las API antiguas, al no poder usar streams, etc.
- Aumento del costo del soporte 1 del proveedor: tiene que pagar soporte para obtener parches de seguridad, y cuanto mayor sea el lanzamiento, más pagará (creo)
- dificultad de retener a los desarrolladores de Java para trabajar en proyectos de Java 5,
- ya no se desarrollan y admiten bibliotecas de terceros de Java para Java 5,
- cuestiones de cumplimiento; eg https://.com/a/3434063/139985
- y así.
Pero cuanto más demore el cliente la actualización, mayor será el salto en la versión de Java y más trabajo (y potencialmente dolor) que se verá involucrado.
Y cuanto más demora el cliente, mayores son los costos acumulados de cosas como aprovisionamiento de hardware, costos de desarrollador, proyectos diferidos, etc.
Para ilustrar, supongamos que ha esperado 10 años para actualizar de Java 1.1 a Java 1.2. Eso significaría que habría gastado 10 años adicionales desarrollando aplicaciones que usaban Hashtable y Vector como sus estructuras de datos principales. Y cuando finalmente se haya actualizado, tendrá 10 años de código "legado" adicional que es más difícil de mantener que si se hubiera escrito utilizando colecciones Java 1.2.
Pero la conclusión es que si el cliente insiste en quedarse con una versión anterior de Java, debe aceptar sus deseos (¡y asegurarse de que transfiera los costos adicionales!) O encontrar una forma de salir de sus relaciones contractuales. con el cliente.
1 - Las fechas de Fin de vida útil / Fin de servicio varían de un proveedor a otro, pero AFAIK todos los principales proveedores ya tienen EOL en Java 5. De hecho, Oracle también tiene Java 6 y Java 7 de EOL.
Dado que pareces estar al tanto de todos los beneficios obvios de java 6, y el cliente tiene buenas razones para ser conservador, todo lo que queda es enfatizar que no cambiar a java 6 obstaculizará el desarrollo.
El desarrollo será más lento porque, sin duda, dedicarás tiempo a implementar la funcionalidad que obtienes de forma gratuita en las versiones más recientes . Y lo peor de todo es que, al no actualizarse regularmente, una actualización es más dolorosa con el paso del tiempo, hasta el punto en que se vuelve prácticamente imposible .
Típicamente, las actualizaciones vencidas resultan en un escenario altamente impredecible, con una pérdida de producción resultante en toda la compañía durante un período de tiempo largo. (suponiendo que el software impacta una base de usuarios lo suficientemente grande dentro de la compañía)
De la source :
P: ¿En qué se diferencia Java SE 6 de la versión anterior (J2SE 5.0)? ¿Cuáles son las áreas mejoradas y actualizadas, como la funcionalidad, la seguridad y el rendimiento?
R: Cualquiera que tenga aplicaciones Java existentes, se beneficiará inmediatamente del rendimiento, la confiabilidad y las mejoras de la interfaz de usuario en Java SE 6. Junto con las capacidades ampliadas de monitoreo y diagnóstico integradas en la plataforma, el lanzamiento ofrece un espectacular out-of-the-box beneficios sin ningún cambio de codificación o incluso una nueva compilación necesaria. Simplemente ejecutar aplicaciones Java existentes en esta última versión es todo lo que se necesita.
Más sobre el mismo tema (puede ser de ayuda para elaborar más para el cliente):
El reclutamiento / retención del personal se convierte en un problema si la aplicación se ve pasada de moda. Los desarrolladores no suelen querer quedarse si no ven progresión.
En Short Java 6 está más optimizado, mejor rendimiento, confiable y actualmente compatible. También proporciona opciones avanzadas como diagnósticos, depuración, etc.
La mayoría de la tecnología basada en Java ya se migró o migró a Java 6. Incluso detendrían la compatibilidad con versiones anteriores.
En lugar de convencerlo de que no existen riesgos, le sugiero que trabaje con él para llegar a una estrategia de mitigación de riesgos.
En otras palabras, acepta que si puede demostrar que el sistema que se ejecuta con Java 6 pasa las pruebas X, Y y Z, estará encantado de actualizar.
Java 5 ya ha pasado su fecha de finalización de la vida útil . Sun / Oracle ya no le emitirá actualizaciones públicas.
Java SE 5.0 se encuentra en su período de transición de End of Life (EOL) de tecnología de Java. El período de transición de EOL comenzó el 8 de abril de 2007 y finalizará el 8 de octubre de 2009, cuando Java SE 5.0 haya alcanzado su fin de vida útil (EOSL).
Si encuentra un error en Java5 ahora (por ejemplo, un bloqueo de punto de acceso - suceden), está jodido. Si tiene un contrato de soporte dedicado con Sun / Oracle, que ofrecen para aquellos que están atascados en versiones obsoletas, entonces pueden solucionarlo por usted.
Podría argumentar que el riesgo de permanecer en una plataforma no admitida es mayor que el riesgo (más manejable) de migrar.
Solo dile que es una actualización menor: muéstrale que la versión va de 1.5 a 1.6 usando el comando "-version" . :)
Tuvimos este problema con un cliente el año pasado y nos mantuvimos firmes y dijimos que el desarrollo futuro (contra Java 1.4 en el momento) sería, como mínimo, significativamente más caro en el futuro y, a medida que pasaba el tiempo, quizás ya ni siquiera lo hagamos. ser posible con nosotros Era un riesgo, pero sentimos que valió la pena, ya que nos permitió reducir en gran medida nuestros costos de desarrollo. Obviamente, no fuimos tan directos como dice la línea de apertura. Mostramos al cliente todas las razones por las cuales sería cada vez más caro quedarse como estaban.
Voy a responder desde el punto de vista del cliente.
Nuestra tienda de desarrollo de sistemas todavía está utilizando Java 5. Para migrar a Jave 6, tenemos que probar toda nuestra cartera.
Cuando pasamos de Java 4 a Java 5, el proceso duró 6 meses e implicó algunos cambios de código (la mayoría de los nombres de variables enum se cambiaron para enumerar).
En este momento, nuestra tienda de desarrollo de sistemas ha decidido que los beneficios de Java 6 no valen la pena de la migración,
Su cliente bancario se siente de la misma manera. No migrarán hasta que se los fuerce a migrar a Java 6.