interfaz - swing java

¿Cómo puedo escribir una aplicación Java que pueda actualizarse en tiempo de ejecución? (9)

Me gustaría implementar una aplicación Java (aplicación de servidor) que pueda descargar una nueva versión (archivo .jar) desde una url determinada, y luego actualizarse en tiempo de ejecución.

¿Cuál es la mejor manera de hacer esto y es posible?

Supongo que la aplicación puede descargar un nuevo archivo .jar e iniciarlo. Pero, ¿cómo debo hacer el traspaso, por ejemplo, saber cuándo se inicia la nueva aplicación y luego salir? ¿O hay una mejor manera de hacer esto?

Primera forma: use tomcat y sus instalaciones de implementación.
Segunda forma: dividir la aplicación en dos partes (funcional y actualización) y dejar que la parte de función de reemplazo de parte de actualización.
Tercera forma: en la aplicación del servidor simplemente descarga la nueva versión, la versión anterior libera el puerto vinculado, la versión anterior ejecuta la nueva versión (inicia el proceso), la versión anterior envía una solicitud al puerto de la aplicación a la nueva versión para eliminar la versión anterior. finaliza y la nueva versión elimina la versión anterior. Me gusta esto:

Actualmente estoy desarrollando un JAVA Linux Daemon y también tuve la necesidad de implementar un mecanismo de actualización automática. Quería limitar mi aplicación a un archivo jar, y se me ocurrió una solución simple:

Empaque la aplicación de actualización en la actualización misma.

Aplicación : cuando la aplicación detecta una versión más nueva, hace lo siguiente:

Descargar actualización (archivo Zip)
Extraer aplicación y ApplicationUpdater (todo en el archivo zip)
Ejecutar el actualizador

ApplicationUpdater : cuando se ejecuta el actualizador, hace lo siguiente:

Detener la aplicación (en mi caso un daemon a través de init.d)
Copie el archivo jar descargado para sobrescribir la aplicación actual
Comience la aplicación
Limpiar.

Espero que ayude a alguien.

Escribí una aplicación Java que puede cargar complementos en tiempo de ejecución y comenzar a usarlos de inmediato, inspirados por un mecanismo similar en jEdit. jEdit es de código abierto, por lo que tiene la opción de ver cómo funciona.

La solución utiliza un ClassLoader personalizado para cargar archivos desde el jar. Una vez que están cargados, puedes invocar algún método del nuevo jar que actuará como su método main . Luego, la parte difícil es asegurarse de que se deshace de todas las referencias al código anterior para que pueda ser basura recolectada. No soy un experto en esa parte, lo he hecho funcionar, pero no fue fácil.

Esta no es necesariamente la mejor manera, pero podría funcionar para usted.

Puedes escribir una aplicación de arranque (como el lanzador de World of Warcraft, si has jugado WoW). Ese bootstrap es responsable de buscar actualizaciones.

Si hay una actualización disponible, se la ofrecerá al usuario, manejará la descarga, la instalación, etc.
Si la aplicación está actualizada, permitirá al usuario iniciar la aplicación
Opcionalmente, puede permitir que el usuario lance la aplicación, incluso si no está actualizada

De esta forma, no tiene que preocuparse por forzar la salida de su aplicación.

Si su aplicación está basada en la web, y si es importante que tengan un cliente actualizado, también puede hacer comprobaciones de versión mientras se ejecuta la aplicación. Puede hacerlo a intervalos, mientras realiza una comunicación normal con el servidor (algunas o todas las llamadas) o ambas.

Para un producto en el que trabajé recientemente, hicimos comprobaciones de versión tras el lanzamiento (sin una aplicación de corrección de arranque, pero antes de que apareciera la ventana principal) y durante las llamadas al servidor. Cuando el cliente estaba desactualizado, confiamos en que el usuario salga manualmente, pero prohibimos cualquier acción contra el servidor.

Tenga en cuenta que no sé si Java puede invocar el código de UI antes de que aparezca la ventana principal. Estábamos usando C # / WPF.

Este es un problema conocido y recomiendo no reinventar una rueda: no escriba su propio hack, simplemente use lo que otras personas ya han hecho.

Dos situaciones que debes considerar:

La aplicación debe ser auto-actualizable y seguir ejecutándose incluso durante la actualización (aplicación de servidor, aplicaciones integradas). Vaya con OSGi: Bundles o Equinox p2 .
La aplicación es una aplicación de escritorio y tiene un instalador. Hay muchos instaladores con la opción de actualización. Verifique la lista de instaladores .

La estructura básica de una solución es la siguiente:

Hay un bucle principal responsable de cargar repetidamente la última versión de la aplicación (si es necesario) y ejecutarla.
La aplicación hace lo suyo, pero comprueba periódicamente la URL de descarga. Si detecta una nueva versión, vuelve al lanzador.

Hay varias formas de implementar esto. Por ejemplo:

El iniciador podría ser un script de envoltura o una aplicación binaria que inicie una nueva JVM para ejecutar la aplicación desde un archivo JAR que se reemplaza.
El iniciador podría ser una aplicación Java que crea un cargador de clases para el nuevo JAR, carga una clase de punto de entrada y llama a algún método sobre él. Si lo haces de esta manera, tienes que estar atento a las fugas de almacenamiento del cargador de clases, pero eso no es difícil. (Solo necesita asegurarse de que no se pueda acceder a ningún objeto con clases cargadas desde el JAR después de relanzar).

Las ventajas del enfoque de envoltura externa son:

solo necesitas un JAR,
puedes reemplazar toda la aplicación Java,
cualquier subproceso secundario creado por la aplicación, etc. desaparecerá sin una lógica de apagado especial, y
también puede hacer frente a la recuperación de bloqueos de aplicaciones, etc.

El segundo enfoque requiere dos JAR, pero tiene las siguientes ventajas:

la solución es puramente Java y portátil,
el cambio será más rápido, y
puede retener el estado más fácilmente durante el reinicio (problemas de fuga del módulo).

La "mejor" manera depende de sus requisitos específicos.

También se debe tener en cuenta que:

Existen riesgos de seguridad con la actualización automática. En general, si el servidor que proporciona las actualizaciones se ve comprometido, o si los mecanismos para proporcionar las actualizaciones son susceptibles de ataque, la actualización automática puede llevar a un compromiso del cliente (s).
Presentar una actualización a un cliente que causa daños al cliente podría tener riesgos legales y riesgos para la reputación de su negocio.

Si puedes encontrar una manera de evitar reinventar la rueda, eso sería bueno. Vea las otras respuestas para sugerencias.

Recientemente creé update4j que es totalmente compatible con el sistema de módulos de Java 9.

Incompletamente iniciará la nueva versión sin un reinicio.

Si construye su aplicación utilizando los complementos de Equinox , puede usar el Sistema de Aprovisionamiento P2 para obtener una solución preparada para este problema. Esto requerirá que el servidor se reinicie después de una actualización.

Veo un problema de seguridad al descargar un nuevo contenedor (etc.), por ejemplo, un hombre en el ataque central. Siempre debe firmar su actualización descargable.

En JAX2015, Adam Bien contó sobre el uso de JGit para actualizar los binarios. Lamentablemente no pude encontrar ningún tutorial.

Fuente en alemán.

Adam Bien creó el actualizador ver aquí

Lo bifurqué here con algunos frontend javaFX. También estoy trabajando en una firma automática.