¿Cuáles son las diferencias entre los diversos complementos de Java para la recarga de clase caliente y cuál es la más intuitiva?

dynamic plugins (2)

Hay un nuevo chico en el bloque, RelProxy , es de código abierto, no es tan avanzado como JRebel pero se puede usar para cambiar libremente un subconjunto de tu código en tiempo de ejecución y volver a cargarlo casi sin penalización de rendimiento y sin necesidad de volver a cargar el contexto (sin sesión perdida) en desarrollo y producción si lo desea.

Actualmente estoy tratando de implementar la recarga de clase caliente en una aplicación Java, sin embargo, hay muchos complementos para elegir y no puedo encontrar una buena comparación entre las opciones. Además, los sitios web de los complementos no son muy claros sobre cuáles son las características exactas y cómo usarlas.

También existe la opción de hacer un ClassLoader recargado de clase caliente personalizado , pero creo que es similar a "reinventar la rueda" si ya hay tantos complementos que pueden hacer el trabajo ... ¿otras personas están de acuerdo con esto?

Los complementos de Java que encontré que creo que pueden hacer el trabajo:

Entonces, ¿alguien sabe cuáles son las diferencias entre los complementos? ¿Y también qué complemento es el más intuitivo de usar?

Como nota al margen: lo que realmente quiero hacer es volver a cargar una dependencia .jar-file de mi aplicación java. Tengo un código de Java que se vuelve a compilar automáticamente muy a menudo y luego se convierte a un archivo .jar. Es una dependencia de mi aplicación java, y mi aplicación necesita usar la versión más nueva de este archivo .jar cada vez.

Descargo de responsabilidad: Estoy involucrado con el desarrollo de JRebel y, por lo tanto, mi respuesta puede parecer un poco parcial, pero haré todo lo posible para explicarlo.

Para responder a esta pregunta, primero quiero llamar su atención sobre el hecho de que una de las principales diferencias entre los nombres que ha enumerado es: algunas de las soluciones requieren que cambie el diseño de la aplicación, otras no.

Las soluciones de modularización, como OSGi o JBoss Modules, proporcionan beneficios si sigue el camino correcto y modulariza su aplicación. De lo contrario, si despliega un paquete de silo, básicamente significa que está reiniciando / volviendo a implementar toda la aplicación, lo que disminuye los beneficios obtenidos de este enfoque.

Play Framework es en realidad un framework full-stack que tiene las capacidades de implementación en caliente. Esas capacidades varían según la versión del marco que utilice. Pero, nuevamente, la misma historia que con la modularidad: el marco impone un cierto modelo de programación.

Apache Commons JCI no es realmente una solución para actualizar el código en caliente. AFAIK, simplemente compila y carga la clase a través de un nuevo cargador de clases. Esto también implica cambiar el código de la aplicación como en los casos mencionados anteriormente. No estoy muy seguro de si es bueno o malo. La desventaja es que difícilmente se puede hacer una integración amplia con el ecosistema de esta manera. Este enfoque es bastante factible para un marco hecho a sí mismo que haría uso de esta característica. Yo prefiero usar un lenguaje de scripting como Groovy, JRuby o JavaScript para lograr lo mismo. Algo como this , por ejemplo.

JRebel , Fakereplace y DCEVM : a esos tipos no les importa el modelo de programación. Pero la diferencia es bastante grande:

DCEVM parchea la JVM y su objetivo es proporcionar una solución de hotswap completa, lo que hace.

JRebel es un agente de Java (conectado con el argumento -javaagent VM), que instrumenta el código de la aplicación y carga las nuevas versiones de las clases al versionarlas. El principal valor de JRebel es que proporciona una configuración flexible junto con una gran cantidad de integraciones específicas del marco , por lo que puede hacer mucho más que un simple intercambio de clases de Java. Por ejemplo, agregue y autoarquee nuevos beans en el contexto de la aplicación Spring, agregue nuevos EJB sobre la marcha, y nuevas acciones de Struts, etc.

Fakereplace también es un agente instrumental, como JRebel, pero tiene mucho menos soporte para los cambios de código Java (supongo) y la cantidad de marcos admitidos no es tan impresionante.

Feenix puede hacer todo lo que la API de instrumentación de Java le permite. Lo que básicamente significa que realmente no agrega valor sobre HotSwap estándar de la JVM. Lo mismo para AgentSmith

ACTUALIZACIÓN: esta respuesta motivó al autor de Feenix a presentar una nueva versión: Feenix 2.0, que se asemeja a la forma en que JRebel trabaja con las clases. Pero como dice el autor, Feenix sigue siendo muy inferior a JRebel. También hay un par de soluciones similares, como HotswapAgent y Spring Loaded : esas herramientas también ofrecen funcionalidades similares pero limitadas a su manera.

Ahora un poco sobre su problema específico , cómo podría resolverse con JRebel:

Cada módulo de la aplicación debe tener su propio archivo de configuración, rebel.xml . Por módulo, nos referimos a EAR, WAR o cualquiera de las dependencias JAR en WEB-INF / lib (como en su caso) o bibliotecas específicas del servidor. El archivo de configuración apunta al directorio donde están las clases compiladas y JRebel cargará las clases directamente desde esa ubicación. Esto significa que no necesita ensamblar el JAR completo una vez que realiza un cambio en una clase Java. En cambio , realiza un cambio y compila la fuente (aprovecha el IDE, en lugar de un script de compilación). JRebel volverá a cargar la clase compilada una vez que se invoque la clase dentro del código de la aplicación.