¿Qué razones tuvieron las personas para escribir su propio cargador de clases?

Question

Recientemente me preguntaron en una entrevista sobre el orden en que se llaman los cargadores de clases cuando se carga una clase.

Desafortunadamente, nunca he tenido la necesidad de escribir mi propio cargador de clases, por lo que en ese momento no estaba familiarizado con las complejidades de la carga de clases.

Esto me hizo preguntarme, ¿qué razones tienen para escribir su propio cargador de clases.

Así que esa es mi pregunta: ¿Qué escenarios enfrentaron las personas que requirieron la necesidad de escribir sus propios cargadores de clases?

Answer 1

La razón más común es que su aplicación aloja otras aplicaciones que usan las mismas bibliotecas en versiones diferentes en el mismo tiempo de ejecución (por ejemplo, Tomcat). Por lo tanto, debe asegurarse de que su cargador de clases pueda proporcionar diferentes versiones de la misma clase para cada una de estas aplicaciones.

EDITAR:

Para aclarar esto un poco (ver la confusión en los comentarios): Cuando dicho "su cargador de clase" I ment "una implementación de java.lang.ClassLoader" no es una instancia de una clase tal. En realidad, es su classloader s en ambos sentidos: la gente de Tomcat implementó diferentes ClassLoader -classes y tienen incluso más instancias en tiempo de ejecución ... para más detalles, vea el corresponding docs.

Answer 2

Tuve que implementar un ClassLoader una vez cuando quería cargar clases en archivos .jar desde un archivo .jar (esto fue hace unos años, estoy seguro de que ahora hay herramientas que pueden hacer eso por usted) es decir, pondría sus archivos .jar de dependencia en un archivo .jar.

Pero esa es la única vez, en mi experiencia escribiendo un ClassLoader personalizado es algo bastante raro.

Answer 3

Echa un vistazo a este question.

Answer 4

Algunos lugares realmente almacenan clases en una base de datos (bueno, solía haber lugares, no estoy seguro si ya existen) y usan un cargador de clases para obtener las clases de la base de datos en tiempo de ejecución.

Answer 5

Actualmente estoy trabajando en una aplicación extremadamente grande que está altamente modularizada, es decir, consta de literalmente cientos de archivos JAR. Esto significa que la cadena classpath se convirtió en enorme, causando todo tipo de problemas en todo tipo de lugares, debido a la incapacidad de varias herramientas de desarrollo para tratar con una cadena classpath de 5KB. Esto se solucionó escribiendo un cargador de clases personalizado que lea su ruta de clases desde un archivo.

Answer 6

Teníamos un marco de aplicación que tenía aplicaciones basadas en él que estaban 'vinculadas estáticamente'. Esto significaba que necesitabas tener una instancia de jvm por cada aplicación que querías ejecutar, lo que no solo era malo para el uso de la memoria, sino que significaba que no podrías tener una súper aplicación desde la que ejecutar las distintas aplicaciones, o cualquier otra aplicación fácil (no interproceso) comunicación entre las aplicaciones en ejecución.

Dado que todo se ejecutó desde webstart (es decir, con un grupo de jar como classpath), la solución para evitar que el cargador de clases del sistema encontrara las clases fue compensar los paquetes. Para expample si tenía una clase a.b.X en una aplicación foo, entonces estaría en el archivo jar como foo/a/b/X.class.

Answer 7

Aburrimiento y el deseo de atormentar a mis compañeros de trabajo cuando tenían que mantener mi código. :)

Answer 8

En mi último trabajo implementamos un servidor que podría tener "definiciones de consulta lógica de complemento". (El cliente podía llamar consultas por nombre, el servidor buscaba la consulta registrada para ese nombre y lo ejecutaba).

Las definiciones de consulta fueron código y/o metadatos contenidos en un jar.

El jar se cargó en el servidor a través de nuestra aplicación de consola.

Cuando se carga (y más tarde cuando se reinicia el servidor), nuestro marco crearía un cargador de clases para que el contenedor lo cargue en el servidor en ejecución.

Answer 9

Encontré un article que explica por qué (muy brevemente) OSGI usa un cargador de clases personalizado.

Answer 10

Tengo que hacer una sola vez. Tenemos que usar una API proporcionada por un proveedor externo, y esta API usa una versión extraña de hibernate3.jar. Por lo tanto, tuvimos que cargar este jar específico con un cargador de clases personalizado para evitar la excepción de "UID de la versión en serie".

Answer 11

He visto una buena publicación here. Habla sobre diferentes cargadores de clases, jerarquía de cargador de clases y cargador de clases personalizado.

Answer 12

Puede hacer lanzamientos de software sin el tiempo de inactividad, un poco de situaciones en sistemas que funcionan 24x7.
Puede escribir su propia llamada de cargador de clases desde JMX y reemplazar el archivo de clase en tiempo de ejecución.