Migrar de Struts 1 a ¿JSF? ¿Struts 2? ¿Tapestry? ¿Spring MVC?

Aunque ya desde el 2008 que salió la última actualización a Struts 1, el año pasado se dió oficialmente la noticia del fin de Struts 1...

Será más fácil migrar a Struts 2? o es mejor migrar a Tapestry 5 ó a JSF? ¿Qué tal a Spring MVC si mi proyecto ya utiliza Spring 2.5?

No existe una urgencia de hacerlo, por lo que puede ser una migración medianamente lenta y gradual, los nuevos requerimientos al proyecto ya existente hacerlos bajo el nuevo FrameWork (de tal forma que estarían conviviendo Struts 1 y el nuevo Framework).

Bajo el escenario anterior, ¿Cuál sería la opción más viable en términos de menos impacto y riesgo?

Saludos!!

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.

Spring MVC

Yo me iría con Spring MVC, sobre todo por el hecho de que tu back-end lo tienes con Spring-Core. Para los componentes de la vista puedes optar por los cientos de Frameworks js que hay en el mercado, yo te recomiendo Angular js por su fácil integración con Spring MVC mediante peticiones Restful o json.

Saludos!

Imagen de oscarblancarte

No nos dejemos llevar por lo nuevo

Hola.
Personalmente creo que antes de pensar en una migración, evalúes si realmente es necesario migrar de framework, es muy común que como programadores siempre queramos utilizar los nuevos framework y las ultimas versiones en todo, sin embargo esto no es del todo bueno, ya que cada versión o framework puede inyectar nuevos errores a nuestra aplicación la cual ya ha sido probada y sabemos que funciona.

Te comento que en la actualidad existe aplicaciones corriendo sobre framework viejos e incluso versiones de Java bastante antiguas las cuales no han sido migradas por la simple razón de que la aplicación funciona bien.

A hora, si por alguna razón decides que migrar de framework y vez que es la mejor opción yo te recomendaría JSF por dos razones, La primera es que ya cuenta con MVC de forma nativa, es decir, no necesitas un framework para soportar MVC, y la segunda y la mas importante es que es parte del Estándar de Java EE.

Imagen de ezamudio

Migrar

Si es una aplicación que sabes que seguirá siendo utilizada por un tiempo más, yo sí te recomiendo migrar, o al menos actualizar. Eso de que "si funciona bien, ahí déjala" pues no siempre es bueno, sobre todo a largo plazo: en algún momento puede cambiar alguna necesidad de los usuarios de esa aplicación y hay que meterle mano. Y meterle mano a una aplicación con cosas muy viejas se vuelve bastante complicado porque tienes que conseguir la JVM vieja y versiones muy viejas de todo y estás programando como en una cápsula del tiempo y es frecuente que te topas con problemas que sabes que se pueden solucionar bien fácil con algunas bibliotecas existentes pero resulta que no corren en esa versión de JVM, etc.

El mejor momento para actualizar cosas de ese tipo es cuando están estables, es decir, si no hay nada urgente que moverle. Obvio no haces nada en producción, pero pues es algo así el proceso:

1. Si no tienes una batería completa de pruebas, implementas una, para probar de manera automática toda la funcionalidad de la aplicación, empezando por las partes más críticas. Esto es esencial antes de mover cualquier cosa en la aplicación.
2. Haces un branch en tu sistema de control de versiones
3. Compilas todo como está pero en la JVM más nueva o una muy reciente (por ejemplo si está en 1.4 puedes tratar de compilar todo en Java o hasta de una vez en Java 8).
4. Modificas todo lo que tengas que modificar (quitar clases obsoletas por ejemplo) hasta que compile y corra bien en Java 8 (corriendo las pruebas en cada paso para que veas que no se descompuso nada, por esto es que son esenciales tenerlas antes de empezar).

Con esos 4 pasos ya lograste actualizar tu aplicación a Java 8, aunque sigas usando las versiones viejas de todos los frameworks. Esto aunque parezca muy simple te podrá dar mejoras en desempeño por ejemplo, y puede que incluso los usuarios lo noten. Cuando menos, sabes que ya no tienes que seguir usando una JVM obsoleta que ya no hay soporte ni mejoras ni nada para esa versión.

Y luego puedes aplicar un proceso similar para actualizar versiones de tus bibliotecas externas. Por ejemplo para actualizar a Spring 4, aunque dejes struts 1 por el momento. Aunque este tipo de actualizaciones requieren un paso adicional, que es analizar bien las diferencias entre versiones y sobre todo qué novedades trae la versión más reciente, porque si bien podrías simplemente usar Spring 4 con un mínimo de modificaciones de Spring 2, seguramente te darás cuenta que hay muchas mejoras y que puedes modificar bastante tu código e incluso el diseño de algunos componentes para aprovechar esas novedades.

El caso de Spring es un tanto especial. Pero después de esto, antes de querer migrar a cualquier otro framework yo te recomendaría hacer un buen análisis de tu aplicación, y aplicar un refactoring de modo que toda la lógica más crítica de la aplicación quede aislada del framework que estés usando; esto te facilitará moverte a otro framework sin tanta bronca.

En mi chamba seguimos sufriendo después de varios años por un problema con una aplicación que comencé yo en Tapestry 3, porque era lo mejor para desarrollar web en ese momento, pero resulta que pues hicimos muchas cosas que dependían de ese framework y luego cuando salió la versión 4 era totalmente incompatible con la 3, los cambios eran demasiados y no hubo tiempo de hacerlo; luego salió la 5 y de plano era una cosa tan diferente que ya iba a ser el mismo esfuerzo "actualizar" a Tapestry 5 o cambiarnos a cualquier otro framework. Por lo tanto estuve revisando los frameworks que había en ese momento y me decidí por Grails, y un criterio muy importante fue que los desarrolladores de Grails siempre se han enfocado mucho en facilitar la migración de aplicaciones a versiones más nuevas, cosa que el señor Howard L. Ship (autor de Tapestry) siempre le valió gorro y hasta parece que cada versión prefiere reescribir el framework para hacerlo incompatible con el anterior para que algunos clientes lo contraten para hacerles la actualización de sus aplicaciones porque es muy complejo el proceso.

Menciono todo esto porque tengo entendido que el cambio de Struts 1 a Struts 2 es tan diferente que muchos opinan que ni siquiera deberían tener el mismo nombre. Y cuando pasa eso y te das cuenta que el esfuerzo va a ser muy grande, pues la verdad es que da igual actualizarte a la versión más nueva o cambiarte por completo a otro framework.

Imagen de oscarblancarte

Re: Migrar

Creo que nos acabas de leer la biblia o algo a sí, tus comentarios esta justificados sin embargo creo que tu comentario "si funciona bien, ahí déjala" esta un poco fuera de lugar, no se trata de "si funciona bien, ahí déjala" se trata de analizar, como lo mencione, si realmente se necesita una migración, yo no puedo decir SI migralo o NO lo migres por que no conozco el desarrollo de nuestro amigo.

Por otra parte, por su puesto que existen escenarios en los que las versiones no se tocan, debido a que son procesos tan críticos y que ya están probados para versiones especificas de Software ya sea JVM o Framework que hacer una migración de versión puede implicar volver a probar todo el aplicativo y arriesgarse a tener nuevos problemas en ambientes productivos.

Personalmente creo que tu opinión fue la de un programador entusiastas que busca actualizar una aplicación sin primero valorar si esto es realmente necesario. justificando los cambios con la única razón de tener la ultima versión.

Imagen de ezamudio

no lo inventé yo

Estoy parafraseando el famoso "if it works, don't fix it". Yo soy de la idea que el software no es algo estático; tanto el que está en producción como el código fuente son cosas que siempre son susceptibles de cambio. Como mencioné inicialmente, a veces por factores externos conviene hacer aunque sea un mínimo esfuerzo por mantener las cosas "al corriente", en el caso de aplicaciones Java pues al menos asegurarse que corran en una versión reciente de la JVM aunque sea sin recompilarlas ni nada. Por esto es importante tener ambientes de pruebas y de staging.

Nadie podemos decir de manera autoritaria si el sistema en cuestión debe ser migrado o no. Pero pues vinieron a preguntar y por eso presento mi opinión.

Sí soy entusiasta, más no busco actualizar una aplicación sin valorar si es necesario. Para empezar esa actualización del sistema por el que preguntan no la voy a hacer yo. En lo que respecta a mi trabajo, pues dado que tenemos aplicaciones que estamos modificando contínuamente, lo mejor es tenerlas actualizadas, porque como ya relaté en el post anterior, ya tuvimos la experiencia de dejar una aplicación "estancada" en cierta versión de los frameworks utilizados hasta llegar al momento en que es necesario reescribirla porque ya ni siquiera corre bien en contenedores más recientes, de modo que hay que tenerle su ambiente especial con Java 6, JBoss 4, etc y es bastante engorroso tener que mantener eso como en un museo.

Parte del trabajo de desarrollo (al menos en mi caso) es mantener las cosas actualizadas. Pero toda actualización se debe hacer con cuidado, por eso menciono los pasos a seguir de manera general, no es nada más instalar en producción la última JVM recién salidita de Oracle; hay que ver si corre la app sin modificarle nada, y también ver qué tal corre si la recompilamos usando el nuevo JDK, y ver si todas las dependencias ya soportan la nueva versión de Java, etc. Es tedioso a veces, pero vale la pena sobre todo cuando resulta que después de probar un rato te das cuenta que una aplicación que funcionaba bien, ahora tiene mejor desempeño sin haber siquiera recompilado, simplemente por usar una JVM más reciente.

Y por último, creo que si existe algún software corriendo que de plano nadie puede tocar porque todo está "con alambritos", no se puede mover ninguna versión de nada, pues no está bien hecho. Deben existir ambientes de pruebas y pruebas automatizadas y manuales, bien definidas, para asegurarse que ese software hace lo que debe y lo hace bien; esas mismas pruebas son las que te permiten hacer regresiones en cada paso de una actualización.

Imagen de ElderMael

Riesgos por no migrar

El no migrar también puede generar al menos un riesgo que yo me he topado muchas veces:

Si sigues agregando funcionalidad usando siempre las mismas versiones de librerías y servidores tarde o temprano te vas a topar con bugs en la version especifica que estás usando.

E.g., agregando una funcionalidad nueva a un sistema, nos decidimos a usar una API de administracion de HornetQ. Desgraciadamente, un componente de la implementación del API tenia un bug que afortunadamente estaba ya detectado pero lo habían arreglado en una version mas reciente de HornetQ... la cual no funcionaba con Java 5. Y pues para no hacerla larga tuvimos que implementar un workaround que hasta el día de hoy me parece un parchesote horrible.

Y lo malo es que por ejemplo, aunque ese bug se habia arreglado, hay veces en que los marcan como WON'T FIX porque ya fue la última version de la librería o porque es la version de la comunidad y el parche solo existe para quienes pagan por mantenimiento (eso me recuerda mucho a JBoss y su modelo de negocios antes de WildFly).

Y podria dar varios ejemplos que me han pasado con casi toda librería, servidor y maquina virtual: Guava, Spring, Hibernate, HornetQ, Tomcat, JBoss, Hostpot, etc. etc. etc. pero mi punto sigue siendo el mismo: si no migras tarde o temprano tu software se va a quebrar.

Imagen de WinDoctor

Gracias

A todos Gracias por sus aportes.

No hay un motivo fuerte por la cual migrar. La idea de migrar es solo eso, una idea hasta el momento, idea de un "desarrollador entusiasta" jejeje, previendo a futuro algún tipo de problemas, por ello les mencioné que podía ser una migración gradual, sin prisas.

Este sistema productivo es un sistema de cobranza para el banco X. Cuándo lo tomé a mi cargo no tenía nada batería de pruebas y hasta hace unos meses lo migré a Maven, sin embargo ésta versión aún no lo subo a productivo. La actualización a una versión de Java 8 no depende de mi, sino del área de Operaciones, que llevan la administración y configuración de servidores y demás Fierros. Actualmente la versión productiva es Java 6, seguramente para el próximo año se migrará a Java 7, pues veo que nunca migran a la versión actual.

La migración del Framework si está en mis manos y en lo personal me gustó mucho lo que he visto de Tapestry y pareciera facilitar la migración. La intensión no es migrar cada que el Framework se actualiza. Si ya tuvimos un ciclo de vida de 10 años con Struts 1 donde evolucionó muy poco, no le veo tanto problema usar Tapestry 5 para que en 6 meses salga Tapestry 6 y sea incompatible con la versión anterior.

Gracias a todos por sus comentarios