stringtranslate.com

Cargador de clases de Java

El cargador de clases Java , parte del entorno de ejecución Java , carga dinámicamente las clases Java en la máquina virtual Java . [1] Normalmente, 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 Java no necesita saber acerca de los 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]

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

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 .

Cargadores de clases definidos por el usuario

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):

Cargadores de clases en Jakarta EE

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 del JAR

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 proceso comunitario Java (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]

Véase también

Notas al pie

  1. ^ Estas bibliotecas se almacenan en archivos Jar llamados rt.jar , core.jar , server.jar , etc.

Referencias

  1. ^ Mcmanis, Chuck (1 de octubre de 1996). "Los conceptos básicos de los cargadores de clases de Java". JavaWorld . Consultado el 13 de julio de 2020 .
  2. ^ abcd Horstmann 2022, §10.1.1 El proceso de carga de clases.
  3. ^ Horstmann 2022, §8.2.5 Escritura de códigos de bytes en la memoria.
  4. ^ ab Christudas, Binildas (26 de enero de 2005). "Internals of Java Class Loading" (Fundamentos internos de la carga de clases en Java). onjava.com . Archivado desde el original el 10 de mayo de 2018.
  5. ^ ab "Comprensión de la carga de clases de extensión". Tutoriales de Java. docs.oracle.com . Consultado el 13 de julio de 2020 .
  6. ^ Sosnoski, Dennis (29 de abril de 2003). "Clases y carga de clases". IBM DeveloperWorks . Consultado el 26 de enero de 2008 .
  7. ^ Horstmann 2022, 10.1.2 La jerarquía del cargador de clases.
  8. ^ Roubtsov, Vladimir (9 de mayo de 2003). "Cómo descifrar el código de bytes de Java". JavaWorld . Consultado el 13 de julio de 2020 .
  9. ^ deBoer, Tim; Karasiuk, Gary (21 de agosto de 2002). "J2EE Class Loading Demystified". IBM DeveloperWorks . Consultado el 26 de enero de 2008 .
  10. ^ "Depósito - Incubadora Apache". Archivado desde el original el 1 de junio de 2013.
  11. ^ "Taxonomía de los problemas del cargador de clases con Jakarta Commons Logging".
  12. ^ Mark Reinhold (20 de septiembre de 2010). "Project Jigsaw". Oracle Corporation . Archivado desde el original el 8 de diciembre de 2015.
  13. ^ "Proyecto Jigsaw". Oracle Corporation . Consultado el 29 de noviembre de 2015 .
  14. ^ Bartlett, Neil; Hackbarth, Kai (22 de septiembre de 2016). "Java 9, OSGi y el futuro de la modularidad (parte 1)". InfoQ.

Enlaces externos