Cargador de clases Java

El cargador de clases de Java , que forma parte del entorno de ejecución de Java , carga dinámicamente las clases de Java en la máquina virtual de Java . ^{[ 1 ] [ 2 ]} Normalmente, las clases solo se cargan bajo demanda . La máquina virtual solo cargará los archivos de clase necesarios para ejecutar el programa. ^{[ 3 ]} El sistema de ejecución de Java no necesita conocer los archivos ni los sistemas de archivos, ya que esto se delega al cargador de clases.

Una biblioteca de software es una colección de código objeto relacionado . En el lenguaje Java , las bibliotecas suelen empaquetarse en archivos JAR . Las bibliotecas pueden contener objetos de diferentes tipos. El tipo de objeto más importante en un archivo JAR es una clase Java . Una clase puede considerarse una unidad de código con nombre. El cargador de clases se encarga de localizar las bibliotecas, leer su contenido y cargar las clases que contienen. Esta carga se realiza normalmente "bajo demanda", es decir, no se produce hasta que el programa llama a la clase. Una clase con un nombre determinado solo puede ser cargada una vez por un cargador de clases específico.

Cada clase de Java debe ser cargada por un cargador de clases. ^{[ 4 ] [ 5 ]} Además, los programas Java pueden utilizar bibliotecas externas (es decir, bibliotecas escritas y proporcionadas por alguien distinto del autor del programa) o pueden estar compuestos, al menos en parte, de varias bibliotecas.

Cuando se inicia la JVM, se utilizan tres cargadores de clases: ^{[ 6 ] [ 7 ] [ 3 ]}

1. Cargador de clases Bootstrap
2. Cargador de clases de extensiones
3. Cargador de clases del sistema

El cargador de clases de arranque carga las bibliotecas Java principales ^{[ fn 1 ]} ubicadas en el directorio <JAVA_HOME>/jre/lib(o <JAVA_HOME>/jmods>para Java 9 y versiones posteriores). Este cargador de clases, que forma parte de la JVM principal, está escrito en código nativo. El cargador de clases de arranque no está asociado con ningún objeto. ^{[ 3 ]} Por ejemplo, devuelve . ^{[ 3 ]}ClassLoaderStringBuilder.class.getClassLoader()null

El cargador de clases de extensiones carga el código en los directorios de extensiones ( <JAVA_HOME>/jre/lib/ext, ^{[ 6 ]} o cualquier otro directorio especificado por la java.ext.dirspropiedad del sistema).

El cargador de clases del sistema carga el código que se encuentra en java.class.path, que se asigna a la CLASSPATHvariable de entorno .

El cargador de clases de Java está escrito en Java. Por lo tanto, es posible crear un cargador de clases personalizado sin comprender los detalles de la Máquina Virtual de Java. Aparte del cargador de clases Bootstrap, cada cargador de clases de Java tiene un cargador de clases padre. ^{[ 8 ]} El cargador de clases padre se define cuando se instancia un nuevo cargador de clases o se establece como el cargador de clases predeterminado del sistema de la máquina virtual.

Esto hace posible (por ejemplo):

• para cargar o descargar clases en tiempo de ejecución (por ejemplo, para cargar bibliotecas dinámicamente en tiempo de ejecución, incluso desde un recurso HTTP ). Esta es una característica importante para:
  • Implementación de lenguajes de scripting, como Jython.
  • utilizando constructores de beans
  • permitiendo la extensibilidad definida por el usuario
  • permitir la comunicación entre múltiples espacios de nombres . Este es uno de los fundamentos de los protocolos CORBA / RMI , por ejemplo.
• para cambiar la forma en que se carga el código de bytes (por ejemplo, es posible usar código de bytes de clase Java cifrado ^{[ 9 ]} ).
• para modificar el código de bytes cargado (por ejemplo, para la inserción de aspectos en tiempo de carga cuando se utiliza programación orientada a aspectos ).

Los servidores de aplicaciones Jakarta EE (anteriormente Java EE y J2EE) suelen cargar clases desde un archivo WAR o EAR desplegado mediante un árbol de cargadores de clases, aislando la aplicación de otras aplicaciones, pero compartiendo clases entre los módulos desplegados. Los denominados " contenedores de servlets " se implementan normalmente mediante múltiples cargadores de clases. ^{[ 5 ] [ 10 ]}

El infierno de los JAR es un término similar al infierno de las DLL que se utiliza para describir todas las diversas formas en que el proceso de carga de clases puede terminar fallando. ^{[ 11 ]} Tres formas en que puede ocurrir el infierno de los JAR son:

• Presencia accidental de dos versiones diferentes de una biblioteca instaladas en un sistema. Esto no se considerará un error. El sistema cargará las clases de una u otra biblioteca. Agregar la nueva biblioteca a la lista de bibliotecas disponibles en lugar de reemplazarla puede provocar que la aplicación siga comportándose como si la biblioteca antigua estuviera en uso, lo cual podría ser cierto.
• Varias bibliotecas o aplicaciones requieren versiones diferentes de la biblioteca foo . Si las versiones de la biblioteca foo utilizan los mismos nombres de clase, no hay forma de cargarlas con el mismo cargador de clases.
• Los problemas más complejos del "infierno de JAR" surgen en circunstancias que aprovechan toda la complejidad del sistema de carga de clases. Un programa Java no está obligado a usar un único cargador de clases "plano", sino que puede estar compuesto por varios (potencialmente muchos) cargadores de clases anidados y cooperativos. Las clases cargadas por diferentes cargadores de clases pueden interactuar de maneras complejas que el desarrollador no comprende del todo, lo que da lugar a errores o fallos difíciles de analizar, explicar y resolver. ^{[ 12 ]}

La Alianza OSGi especificó (a partir de JSR 8 en 1998) un marco de modularidad que busca resolver el problema de los archivos JAR para máquinas virtuales actuales y futuras en ME, SE y EE, y que ha sido ampliamente adoptado. Mediante metadatos en el manifiesto JAR , los archivos JAR (denominados paquetes) se organizan individualmente para cada paquete. Los paquetes pueden exportar, importar y mantener paquetes privados, proporcionando así las estructuras básicas de modularidad y gestión de dependencias versionadas.

Java 9 introdujo el Sistema de Módulos de Plataforma Java (JPSS) en 2017. Este especifica un formato de distribución para colecciones de código Java y recursos asociados. También especifica un repositorio para almacenar estas colecciones, o módulos , e identifica cómo se pueden descubrir, cargar y verificar su integridad. Incluye características como espacios de nombres con el objetivo de corregir algunas de las deficiencias del formato JAR existente . El JPSS sigue una filosofía diferente a la de la arquitectura OSGi, que busca proporcionar modularidad para el Entorno de Ejecución de Java (JRE) de forma retrocompatible, utilizando el mecanismo predeterminado de carga de clases que proporciona el JRE. Sin embargo, dado que el JPSS no ofrece la capacidad de coexistencia controlada de bibliotecas con diferentes versiones, no resuelve completamente el problema del "infierno de JAR". ^{[ 13 ]}

• Cargador (informática)
• Carga dinámica
• El infierno de las DLL
• OSGi
• Ruta de clases (Java)
• Sistema de módulos de la plataforma Java

• Chuck McManis, " Los fundamentos de los cargadores de clases de Java ", 1996
• Brandon E. Taylor, " Carga de clases en Java: Lo básico " (Archivado el 9 de noviembre de 2020 en Wayback Machine ), 2003
• Horstmann, Cay (15 de abril de 2022). Java central . Prensa Oracle Java. ISBN 0-13-787107-4.
• Jeff Hanson, " Tome el control de la carga de clases en Java " (Archivado el 4 de diciembre de 2020 en Wayback Machine ), 1 de junio de 2006
• Andreas Schaefer, " Cargadores de clase internos ", 12 de noviembre de 2003
• Sheng Liang y Gilad Bracha, " Carga dinámica de clases en la máquina virtual Java ", En Actas de la 13.ª Conferencia ACM sobre Programación Orientada a Objetos, Sistemas, Lenguajes y Aplicaciones (OOPSLA'98), ACM SIGPLAN Notices, vol. 33, n.º 10, ACM Press, 1998, págs.  36-44 , doi : 10.1145/286936.286945
• Jeremy Whitlock, " Uso práctico de los cargadores de clases personalizados ", mayo de 2005
• Christoph G. Jung, " Cargadores de clases revisados ​​en Hotdeploy ", Boletín de especialistas en Java , 7 de junio de 2001
• Don Schwarz, " Gestión de dependencias de componentes mediante ClassLoaders ", 13 de abril de 2005