Java classloader

El Java Classloader( en español, cargador de clases Java) es una parte del Java Runtime Environment que carga dinámicamente clases Java en la Java Virtual Machine. Normalmente las clases solo son cargadas bajo demanda.

Una biblioteca de software es una colección de código objeto más o menos relacionado. En el Lenguaje de programación Java, las bibliotecas están típicamente empaquetadas en ficheros JAR. Las bibliotecas pueden contener varias clases diferentes de objetos, el tipo más importante de objeto contenido en un fichero Jar es una clase Java. Puede pensarse en una clase como en una unidad nombrada de código. El cargador de clases es responsable de localizar bibliotecas, leer sus contenidos, y cargar las clases contenidas dentro de las mismas. Esta carga es normalmente hecha "bajo demanda", por lo que no ocurre hasta que la clase sea usada por el programa. Una clase con un nombre dado sólo puede ser cargada una vez por un classloader dado.

El proceso de carga de clases es bastante complicado, y es tema de mucha confusión en el Despliegue de software y el Desarrollo de software. Los programas Java pueden hacer uso de bibliotecas externas o de terceras partes (esto es, bibliotecas escritas y suministradas por alguien distinto del autor del programa) o pueden estar compuestas en sí mismas, al menos en parte, por otras bibliotecas.

Infierno de los JAR

Infierno de los Jar es un término general usado para describir todas las distintas formas en las cuales el proceso de carga de clases puede fallar.

• Un caso es cuando un desarrollador o desplegador de una aplicación Java ha puesto accidentalmente dos versiones diferentes de una biblioteca al sistema. Esto no se considera un error del sistema. El sistema podría cargar clases de una o de la otra biblioteca. Por tanto, un desarrollador que piensa que ha reemplazado una biblioteca con una nueva versión, pero el cual ha simplemente añadido la nueva biblioteca a la lista de bibliotecas disponibles, puede sorprenderse de que la aplicación todavía se comporte como cuando la vieja biblioteca estaba en uso, la cual por supuesto, puede estar correcta.

• Otra versión del problema ocurre cuando dos bibliotecas (o una biblioteca y la aplicación) requieren versiones diferentes de la misma biblioteca tercera. Sin tomar medidas extraordinarias (las cuales pueden incluso estar o no disponibles, dependiendo de las circunstancias) no hay forma de cargar ambas versiones de la biblioteca tercera.

• Los problemas más complejos del infierno Jar aparecen en circunstancias que toman ventaja de la complejidad total del sistema de carga de clases. Un programa Java no necesita usar solo un individual classloader, sino que puede estar compuesto de varios classloaders anidados cooperando. Esto no es tan raro como se pudiera pensar: los llamados "servlet containers" están implementados típicamente en términos de múltiples classloaders. Las interacciones entre los classloaders es demasiado compleja para ser explicada completamente aquí. Es suficiente decir que las clases cargadas por diferentes classloaders interactúan en formas que podrían no ser comprendidas perfectamente por el desarrollador, conduciéndole a errores o bugs inexplicables.

Véase también

• Infierno DLL
• Apache Maven, herramienta de software de construcción automatizada con gestión de dependencias

Enlaces externos

• Article "The basics of Java class loaders" by Chuck Mcmanis
• Article "Java Class Loading: The Basics" by Brandon E. Taylor
• Article "Take Control of Class Loading in Java" by Jeff Hanson
• Article "Java programming dynamics, Part 1: Classes and class loading" by Dennis Sosnoski
• API description
• Understanding Extension Class Loading
• Dependency manager - now at Apache incubator
• Dynamic loading of classes directly from JAR files
• ¿Qué versión del JAR se está cargando?