Java-Klassenlader - Java Classloader

Der Java Class Loader ist ein Teil der Java Runtime Environment , der Java-Klassen dynamisch in die Java Virtual Machine lädt . Normalerweise werden Klassen nur bei Bedarf geladen . Das Java-Laufzeitsystem muss nichts über Dateien und Dateisysteme wissen, da dies an den Klassenlader delegiert wird .

Eine Softwarebibliothek ist eine Sammlung zusammengehörigen Objektcodes . In der Sprache Java werden Bibliotheken normalerweise in JAR-Dateien gepackt . Bibliotheken können Objekte unterschiedlichen Typs enthalten. Der wichtigste Objekttyp, der in einer Jar-Datei enthalten ist, ist eine Java-Klasse . Eine Klasse kann man sich als benannte Codeeinheit vorstellen. Der Klassenlader ist dafür verantwortlich, Bibliotheken zu finden, ihren Inhalt zu lesen und die in den Bibliotheken enthaltenen Klassen zu laden. Dieses Laden erfolgt typischerweise "nach Bedarf", da es nicht erfolgt, bis die Klasse vom Programm aufgerufen wird. Eine Klasse mit einem bestimmten Namen kann von einem bestimmten Klassenlader nur einmal geladen werden.

Jede Java-Klasse muss von einem Klassenlader geladen werden. Darüber hinaus können Java- Programme externe Bibliotheken verwenden (dh Bibliotheken, die von jemand anderem als dem Autor des Programms geschrieben und bereitgestellt wurden) oder sie können zumindest teilweise aus einer Anzahl von Bibliotheken bestehen.

Beim Starten der JVM werden drei Klassenlader verwendet:

  1. Bootstrap-Klassenlader
  2. Erweiterungsklassenlader
  3. Systemklassenlader

Der Bootstrap-Klassenlader lädt die Java-Kernbibliotheken, die sich im <JAVA_HOME>/jre/libVerzeichnis befinden. Dieser Klassenlader, der Teil der Kern-JVM ist, ist in nativem Code geschrieben.

Der Klassenlader für Erweiterungen lädt den Code in die Erweiterungsverzeichnisse ( <JAVA_HOME>/jre/lib/extoder ein anderes von der java.ext.dirsSystemeigenschaft angegebenes Verzeichnis ).

Der Systemklassenlader lädt Code, der auf gefunden java.class.pathwurde und der CLASSPATH Umgebungsvariablen zugeordnet ist .

Benutzerdefinierte Klassenlader

Der Java-Klassenlader ist in Java geschrieben. Es ist daher möglich, einen eigenen Klassenlader zu erstellen, ohne die Feinheiten der Java Virtual Machine zu verstehen. Jeder Java-Klassenlader hat einen übergeordneten Klassenlader, der definiert wird, wenn ein neuer Klassenlader instanziiert oder auf den standardmäßigen Klassenlader des Systems der virtuellen Maschine gesetzt wird.

Dies macht es möglich (zum Beispiel):

  • um Klassen zur Laufzeit zu laden oder zu entladen (zum Beispiel um Bibliotheken zur Laufzeit dynamisch zu laden, sogar von einer HTTP- Ressource). Dies ist eine wichtige Funktion für:
    • Implementierung von Skriptsprachen wie Jython
    • mit Bohnenbauer
    • ermöglicht benutzerdefinierte Erweiterbarkeit
    • Ermöglichen der Kommunikation mehrerer Namespaces . Dies ist beispielsweise eine der Grundlagen von CORBA / RMI- Protokollen.
  • um zu ändern, wie der Bytecode geladen wird (beispielsweise ist es möglich, verschlüsselten Java-Klassen-Bytecode zu verwenden).
  • um den geladenen Bytecode zu modifizieren (zum Beispiel für das Laden von Aspekten beim Weben von Aspekten bei der aspektorientierten Programmierung ).

Klassenlader in Jakarta EE

Jakarta EE- Anwendungsserver (ehemals Java EE und J2EE) laden normalerweise Klassen aus einem bereitgestellten WAR- oder EAR- Archiv durch einen Baum von Klassenladern, isolieren die Anwendung von anderen Anwendungen, teilen jedoch Klassen zwischen bereitgestellten Modulen. Sogenannte „ Servlet-Container “ werden typischerweise in Form von mehreren Klassenladern implementiert.

JAR-Hölle

JAR-Hölle ist ein ähnlicher Begriff wie DLL-Hölle, der verwendet wird, um all die verschiedenen Möglichkeiten zu beschreiben, auf denen der Klassenladeprozess nicht funktionieren kann. Drei Möglichkeiten, wie die JAR-Hölle auftreten kann, sind:

  • Versehentliches Vorhandensein von zwei verschiedenen Versionen einer Bibliothek, die auf einem System installiert ist. Dies wird vom System nicht als Fehler gewertet. Stattdessen lädt das System Klassen aus der einen oder anderen Bibliothek. Wenn Sie die neue Bibliothek der Liste der verfügbaren Bibliotheken hinzufügen, anstatt sie zu ersetzen, kann die Anwendung dazu führen, dass sich die Anwendung immer noch so verhält, als ob die alte Bibliothek verwendet würde, was durchaus der Fall sein kann.
  • Mehrere Bibliotheken oder Anwendungen erfordern unterschiedliche Versionen von Bibliothek foo . Wenn Versionen von Bibliothek foo dieselben Klassennamen verwenden, gibt es keine Möglichkeit, die Versionen von Bibliothek foo mit demselben Klassenlader zu laden .
  • Die komplexesten JAR-Höllenprobleme treten unter Umständen auf, die die volle Komplexität des Classloading-Systems ausnutzen. Ein Java-Programm muss nicht nur einen einzigen "flachen" Klassenlader verwenden, sondern kann stattdessen aus mehreren (möglicherweise sehr vielen) verschachtelten, kooperierenden Klassenladern bestehen. Klassen, die von verschiedenen Klassenladern geladen werden, können auf komplexe Weise interagieren, die von einem Entwickler nicht vollständig verstanden wird, was zu Fehlern oder Bugs führt, die schwer zu analysieren, zu erklären und zu beheben sind.

Die OSGi Alliance spezifizierte (beginnend als JSR 8 im Jahr 1998) ein Modularitäts-Framework, das darauf abzielt, die JAR-Hölle für aktuelle und zukünftige VMs in ME, SE und EE zu lösen, die weit verbreitet ist. Mithilfe von Metadaten im JAR- Manifest werden JAR-Dateien (so genannte Bundles) paketweise verbunden. Bundles können Pakete exportieren, Pakete importieren und Pakete privat halten, wodurch die grundlegenden Konstrukte der Modularität und des versionierten Abhängigkeitsmanagements bereitgestellt werden.

Um die JAR Hölle Probleme zu beheben, ein Java Community Process  - JSR 277 im Jahr 2005 initiiert wurde , um die Auflösung - Java - Plattform - Modul - System  - sollte ein neues Vertriebsformat einzuführen, ein Module Schemas Versionsverwaltung und eine gemeinsame Module Repository (ähnlich Zweck Microsoft .NET ‚s Global Assembly Cache ). Im Dezember 2008 gab Sun bekannt, dass JSR 277 auf Eis gelegt wurde. Das Java Module System wurde später als "Projekt Jigsaw" neu gestartet, das in Java 9 enthalten war .

Siehe auch

Fußnoten

Verweise

Externe Links