El cargador de clases de Java , parte del entorno de ejecución de Java , carga dinámicamente las clases de Java en la máquina virtual de Java . [1] Por lo general, las clases solo se cargan a pedido . La máquina virtual solo cargará los archivos de clase necesarios para ejecutar el programa. [2] El sistema de ejecución de Java no necesita saber sobre archivos y sistemas de archivos, ya que esto se delega en el cargador de clases.
Una biblioteca de software es una colección de código de objetos relacionados . En el lenguaje Java , las bibliotecas suelen estar empaquetadas en archivos JAR . Las bibliotecas pueden contener objetos de diferentes tipos. El tipo de objeto más importante contenido en un archivo JAR es una clase Java . Una clase puede considerarse como una unidad de código con nombre. El cargador de clases es responsable de localizar bibliotecas, leer su contenido y cargar las clases contenidas en ellas. Esta carga se realiza normalmente "a pedido", 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 determinado.
Cada clase Java debe ser cargada por un cargador de clases. [3] [4] Además, los programas Java pueden hacer uso de 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: [5] [6] [2]
El cargador de clases de arranque carga las bibliotecas principales de Java [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 ClassLoaderobjeto. [2] Por ejemplo, devuelve . [2]StringBuilder.class.getClassLoader()null
El cargador de clases de extensiones carga el código en los directorios de extensiones ( <JAVA_HOME>/jre/lib/ext, [5] 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 CLASSPATH variable 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 más finos de la máquina virtual de Java. Aparte del cargador de clases de Bootstrap, cada cargador de clases de Java tiene un cargador de clases principal. [7] El cargador de clases principal se define cuando se crea una instancia de un nuevo cargador de clases o se lo configura como el cargador de clases predeterminado del sistema de la máquina virtual.
Esto permite (por ejemplo):
Los servidores de aplicaciones Jakarta EE (anteriormente Java EE y J2EE) suelen cargar clases desde un archivo WAR o EAR implementado mediante un árbol de cargadores de clases, aislando la aplicación de otras aplicaciones, pero compartiendo clases entre los módulos implementados. Los denominados " contenedores de servlets " se implementan normalmente en términos de múltiples cargadores de clases. [4] [9]
El infierno de los JAR es un término similar al infierno de las DLL que se utiliza para describir las distintas formas en las que el proceso de carga de clases puede dejar de funcionar. [10] Las tres formas en las que puede producirse el infierno de los JAR son:
La OSGi Alliance especificó (a partir de JSR 8 en 1998) un marco de modularidad que apunta a resolver el problema de los JAR para las máquinas virtuales actuales y futuras en ME, SE y EE, que se ha adoptado ampliamente. Mediante el uso de metadatos en el manifiesto JAR , los archivos JAR (llamados paquetes) se conectan por paquete. Los paquetes pueden exportar paquetes, importar paquetes y mantener la privacidad de los paquetes, lo que proporciona las construcciones básicas de modularidad y administración de dependencias con versiones.
Para remediar los problemas del infierno JAR, en 2005 se inició un Java Community Process (JSR 277). La resolución ( Java Platform Module System ) pretendía introducir un nuevo formato de distribución, un esquema de control de versiones de módulos y un repositorio de módulos común (similar en propósito al Global Assembly Cache de Microsoft .NET ). En diciembre de 2008, Sun anunció que JSR 277 se suspendía. [12] El Java Module System se reinició más tarde como "proyecto Jigsaw" [13] que se incluyó en Java 9. Lanzado en 2017, incluye soporte para software modular, denominado "Java Platform Module System", que se controla a nivel de fuente con archivos module-info.java. Sigue una filosofía diferente de la arquitectura OSGi que tiene como objetivo proporcionar modularidad para Java Runtime Environment de una manera compatible con versiones anteriores que utiliza el mecanismo predeterminado de carga de clases que proporciona JRE. Sin embargo, dado que no ofrece la posibilidad de coexistencia controlada de bibliotecas con diferentes versiones, no es adecuado para abordar el problema del infierno JAR. [14]