En un reciente post Matt Raible dice que si tuviera que pedir un deseo para el 2008 sería que todos los frameworks web en Java tuvieran soporte para ZTT.

Matt no usa el término ZTT sino que le dice "hot deploy", pero el concepto es el mismo. En su post menciona Groovy, Grails (que está en Groovy), Seam y Tapestry5 como frameworks que ya lo soportan "out of the box", y comenta que no debería ser necesario comprar JavaRebel para poder usar ZTT en Java sino que debería ser obligación de todo framework proveer esta funcionalidad (cosa que veo un poco difícil).

Yo soy un feliz usuario de JavaRebel y lo recomiendo. La única alternativa FLOSS que conozco es el tomcat launcher plugin de Sysdeo (si alguien conoce alguna más por favor que me lo comente), que viene con un classloader propio. El plugin de sysdeo es excelente pero tiene sus limitaciones, sólo funciona con el IDE Eclipse y con el servidor de aplicaciones Tomcat (cualquiera de sus versiones) y, además, tiene varios problemas especialmente cuando se agregan métodos nuevos a una clase o cuando se cambian parámetros en anotaciones.
JavaRebel, en cambio, funciona con cualquier IDE (incluso funciona con maven :D ) y con varios servidores de aplicaciones. Como contra tiene que no es open source y que su licencia cuesta $150 (aunque bien valen la pena).

Ambas alternativas son incompatibles con cambios de estructura en el modelo Hibernate. Me pregunto como hará Seam para manejar los cambios en el modelo? los detectará? Hmmm tendré que hacer la prueba.

Por cierto, si no saben lo que es JavaRebel no se pierdan el simpático corto animado: "La historia de un rebelde Java" (A Story of a Java Rebel)

Al comenzar a hablar de ZTT en java hay que hacer la siguiente aclaración: es prácticamente imposible asegurar que cualquier estrategia para ZTT para java funcionará en el 100% de los casos.
La principal razón para esto es que no hay una manera estándar establecida de hacer manipulación de bytecode de clases (weaving), y entonces cada framework o librería implementa su manera: algunos usan AspectJ, otros Javassist, otros Jakarta Commons JCI y otros como Tapestry5 implementan su propio ClassLoader.
Esto lleva a que varios esfuerzos para aproximarse a ZTT resulten incompatibles entre si y con determinados frameworks. El caso más típico es Hibernate. En esta serie de post veremos diferentes estrategias para acelerar el desarrollo al utilizar frameworks como Trails, Tapestry4, Tapestry5, Spring. Pero cuando se trata de Hibernate siempre hay que hacer consideraciones aparte, porque al realizar una modificación sobre una clase del modelo Hibernate, no todas las estrategias para ZTT funcionan correctamente. Hibernate tiene su propio weaving de classes (weaving estático con Javassist) que no permite hacer el cambio "on the fly" de una clase sin notificarle a Hibernate y recargar toda la configuración. En otro post mostraré de que manera se puede disminuir el impacto de esta limitación de Hibernate recargando el contexto de Spring.

Tapestry5 seamless ZTT

Una de las nuevas características de Tapesty5 es la recarga automática ("on the fly") de clases o templates que hayan sido modificados (Live Class and Template Reloading).
Lo mejor de la implementación de Tapestry5 es que funciona exactamente igual en desarrollo que en producción y no necesita (prácticamente) ninguna configuración o consideración extra.
Para verlo en funcionamiento se pueden consultar los excelentes screencasts de Tapestry5 que Howard ha preparado como introducción a las diferentes características del framework.
Incluso es realmente fácil de probar para aquellos familiarizados con Maven. Existe un archetype que permite probar estás caracteristicas de Tapesty5 en 10 minutos.
Las limitaciones: Tapestry5 implementa su propio ClassLoader y debido a la ambigüedades en las especificaciones de "class loading" (lo que ha generado varias discuciones) para servidores de aplicaciones, hay que tener ciertas precauciones al usar otros servidores de aplicaciones que no sean Jetty.
Otra limitación es que el class reloading se limita a clases controladas por Tapestry5 IoC, por lo que si el cambio ha sido en clases del modelo Hibernate o alguna clase que se inyecta via Spring, estos cambios no serán detectados.

Tapestry5 "Live Class and Template Reloading" es LO MEJOR (dentro del open source) que he visto para facilitar la vida del desarrollador web java y reducir el tiempo del ciclo de deployment al mínimo posible. Gracias a esta característica creo se convertirá en "él" framework web java del 2008 y seguramente volverá a ganar el premio que otorga Sun a la innovación en Java.

Yo me considero un desarrollador ágil JAVA, o mejor dicho yo me considero un desarrollador ágil Tapestry. Pero he de reconocer que si bien la velocidad de desarrollo con Trails y/o Tapestry está entre las mejores del (sub)mundo JAVA, no sirve ni siquiera como punto de referencia cuando se la compara con la de otros lenguajes y frameworks.
Uno de los principales problemas del desarrollo en JAVA es la agilidad y productividad del programador. Realmente estamos lejos de imitar la agilidad con la que se puede desarrollar en lenguajes como Ruby o PHP, y si hablamos de frameworks web en particular, estamos lejísimos de frameworks como Rails o Akelos.

¿Por qué el desarrollo con Akelos o Rails es tanto más rápido/ágil que el desarrollo con cualquier framework web JAVA?
La clave es el Zero Turnaround Time (ZTT), que podría traducirse como: "Recarga sin demora" o "Recarga inmediata" o "Cero tiempo de recarga".
El ZTT permite que cualquier pequeño cambio en la aplicación se pueda ver inmediatamente en el navegador, simplemente alcanza con hacer "refresh" en el navegador y listo, "feedback inmediato".

El gran beneficio del feedback inmediato es que permite determinar muy rápidamente si los cambios en la aplicación son correctos o no, y ésta es la gran ventaja que hace que el "desarrollo ágil" vaya de la mano con ZTT.

Este es el punto de partida de una serie de posts donde compartiré mis trucos para agilizar mi proceso de desarrollo y para aproximarme (aunque sin alcanzarlo nunca) al ZTT.