Java 5 esta muriendo...

Java 5 esta muriendo... y "Java 2" debería estar muerto.

Hace un año publiqué una nota sobre el fin del ciclo de vida de la última versión de Java SE de lo que conocimos como "Java 2", y con ello se anunciaba la lenta muerte de dicha era (Java 2 esta muriendo). Pues bien, ahora le toca el turno a Java SE 5 (Java SE & Java SE for Business Support Road Map) por lo que, al menos en teoría e idealmente, todos deberíamos estar ya desarrollando sobre, o migrar a, Java SE 6.

No obstante a un año aún veo proyectos "Java 2", y en una encuesta en la que participé (lamentablemente no recuerdodo la url) hubo varios a los que no les importaba demasiado la llegada del fin soporte para Java 5, ya que estarían dispuestos a enrolarse al programa de soporte pagado, pero otros (en ese momento cerca del 40%) simplemente les daba igual y siguirían trabajando en Java 5 sin soporte... como lo dije, esto mismo estoy viendo incluso con "Java 2".

Entiendo que a muchas empresas les resulte "costoso" migrar una aplicación, sobre todo cuando es crítica y funciona "bien". Pero lo que no entiendo es como pueden ejecutar dicha aplicación que es crítica sobre algo que no tiene soporte, eso es simplemente riesgoso y por ende costoso. Pero eso si, el día que truene todo mundo tendrá la culpa menos ellos, los que se negaron a migrar... O será que la culpa es de Sun por crear versiones "robustas" y quererles dar fin tan pronto...

¿Que opinan ustedes del fin de ciclo de vida de Java 5 y "Java 2" y todas las aplicaciones, ahora "legacy", que dejaron...?

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de ezamudio

Migración menos dolorosa

Migrar de Java 1.3 o 1.4 a Java 5 fue algo complicado por la cosa de los generics, pero valió la pena por performance mejorado, clases nuevas (como los thread pools), las anotaciones, etc.

El paso de Java 5 a Java 6 es mucho menos doloroso; de hecho en la página de Sun te recomiendan que si ya tienes aplicaciones en Java 5, simplemente puedes usar el runtime de Java 6 y vas a tener mejoras en performance. Y pues yo empecé a usar Java 6 y no he visto cambios; sé que hay cosas nuevas en Java 6 (como lo de clientes para web services, que ya puedes crear sin necesidad de usar cosas como Apache Axis) pero no he necesitado usar algo particular de esa versión.

Java 1.4 ya debe quedar atrás. Pero tristemente va a seguir vivo un rato. Recientemente me topé con un cliente que nos pidió unas cosas para que corrieran en Java 1.3.1 y fue un rollo porque pues tuvimos que compilar las clases usando el compilador de la 1.3. No importa que le pongas compatibilidad al compilador más nuevo, porque terminas usando clases que no existían; hasta instalar el JDK de la 1.3 me di cuenta de que estaba usando cosas que todavía no existían en esa versión y ya modifiqué todo para entregarles algo que funcionara. Y para echar a andar la 1.3.1 fue un proceso complicado porque tuve que instalar librerías muy viejas en linux, un rollo conseguirlas...

Imagen de luxspes

Supongo que depende de cada

Supongo que depende de cada caso, donde yo trabajo actualmente para algunos sistemas utilizamos OAS/OC4J (el JEE server de Oracle) que es compatible solamente con Java 1.5, al tratarlo de de correr sobre Java 1.6 he podido ver algunos de los raros casos en los que un codigo en Java logra tirar completamente a la JVM 1.6 con un error de corrupcion de memoria de bajo nivel (nada de preciosas stacktraces). Lo mismo me ocurrio cuando trate de correr la primeras versiones de JBoss 4.x sobre JVM 1.6 (solo era compatible con al 1.5 asi que corrompia a la maquina virtual).

Es importante recordar que para medir el riesgo de correr sobre una plataforma "muerta" como Java 1.5 hay sopesarlo con el riesgo de migrar a una plataforma mas reciente, que puede hacer inestable a tu sistema.

En mi caso, pasar lo sistemas de JBoss 4.x a Tomcat 6 (resulto que no requerian ninguna de la caracteristicas avanzadas de JBoss) fue sencillo (gracias Spring), pero los sistemas que estan sobre OAS/OC4J se quedaran ahi largo rato (al menos hasta que la JVM se vuelva MVM o algun application server opensource implemente "provisioning", una caracteristica de OAS/OC4J, muy util para sistemas de mision critica, que no he podido encontrar en ninguna otra parte y sin la cual no podria justificar el abandonar dicha plataforma)

Re: Supongo que depende de cada

WebLogic y WebSphere también proporcionan características que contienen el consumo de recursos de una aplicación: Work Managers y Workload Managers respectivamente. Querría pensar que la versión de paga de Glassfish tiene una característica similar. Pero coincido con tu punto: si ya estás sacando provecho de dichas características avanzadas en un servidor "enterprise", es difícil moverse a uno open source.

Saludos

Javier Castañón

Re: Migración menos dolorosa

También ocurre que las empresas que tienen soporte, es porque generalmente ocupan un servidor comercial, y el servidor comercial tiene soporte para combinaciones específicas de sistema operativo, JVM y servidor de aplicaciones. Así que si se cambia el JDK, se quedan fuera de soporte. Donde presto servicios actualmente espero que el próximo mes migren de servidor de aplicaciones a la nueva versión que por fin soporta Java 5. :-O

Saludos

Javier