2009-01-19 10 views
5

Un cliente requiere una vista previa de una nueva característica de nuestro producto. Pidieron que se les enviara esa característica en un archivo jar (como un parche). No hay problema con incluir las nuevas clases en dicho archivo jar. Sin embargo, se modificó una clase existente, que es necesaria para integrar la nueva característica. Solo quieren agregar este nuevo archivo jar sin tener que actualizar las clases principales de nuestro producto. Entonces, la pregunta es: ¿es posible anular una clase ya existente usando un contenedor separado? ¿Si es así, cómo?¿Cómo puedo anular una clase usando un contenedor separado?

Gracias de antemano.

Respuesta

11

Hay una oportunidad que funcionará si coloca el nuevo jar antes en el classpath que el jar original. Vale la pena intentarlo, aunque todavía suena como una receta para el desastre, o al menos, realmente difícil de solucionar problemas si de alguna manera ambas clases están cargadas.

EDIT: yo había planeado escribir este poco antes, pero he interrumpido por el final de un viaje en tren ...

me gustaría ir de nuevo al cliente y explicar que, si bien lo que están pidiendo es posible , puede causar problemas inesperados. Actualizar el archivo jar es una solución mucho más segura, con mucho menos riesgo. Es probable que las frases "problemas inesperados" y "riesgo" hagan sonar las alarmas con el cliente, por lo que con suerte le permitirán hacer lo correcto.

+1

en mi experiencia, las clases anteriores en el classpath se cargan de manera confiable, mientras que las versiones posteriores no lo son. – Cogsy

+0

Sí, debería funcionar, pero sigue siendo una manera bastante tonta de actualizar algunas clases –

+1

Y las dependencias en las interfaces modificadas todavía pueden quemarlo.Además, una estructura compleja de cargador de clases puede causar que incluso la carga de clases falle si no se actualizan todas las rutas de clase implicadas. – Darron

1

Sí, puede ser posible, colocándolo antes en el classpath que su jar original. Sin embargo, confiar en el orden de tu ruta de clase no siempre te llevará a la felicidad. No estoy seguro de si está incluso documentado en Java Language Spec; si no, se romperá para diferentes JVM e incluso versiones diferentes de la misma JVM.

En su lugar, considere citar un marco de tiempo realista para integrar la nueva característica en la base de código actual. Esta quizás no es la respuesta que estás buscando.

3

Sí y no, depende de su entorno.

Si utiliza, por ejemplo, OSGi y tiene sus versiones bajo control, solo es cuestión de instalar un nuevo paquete con el paquete exportado en una versión superior (suponiendo que los rangos de su versión sean lo suficientemente indulgentes).

Si usa Java simple sin carga de clase personalizada, debería estar listo para colocarlo antes en su ruta de clase (como los otros ya mencionados).

Si tiene cargas de clases personalizadas, necesitará asegurarse de que todas las clases que necesita su clase "parcheada", y todo el casco de dependencia transitiva, sean visibles desde el cargador de clases que está cargando los parches versión, lo que puede significar que necesita enviar la aplicación completa, en el peor de los casos.

2

Todas las respuestas que estipulan que ponen las clases actualizadas antes de que los que están reemplazando en la ruta de clase son correctas, solamente proporcionan el JAR original no está sellado o firmado.

+1

No funciona si el archivo jar está firmado tampoco. – studgeek

0

Probablemente más de lo que necesita para este caso específico, pero en general si solo desea ajustar o aumentar una clase existente, también puede utilizar AspectJ con load-time weaving.

Cuestiones relacionadas