Java-klaslader - Java Classloader

De Java Class Loader is een onderdeel van de Java Runtime Environment dat dynamisch Java-klassen laadt in de Java Virtual Machine . Gewoonlijk worden lessen alleen op aanvraag geladen . Het Java-runtimesysteem hoeft niets te weten over bestanden en bestandssystemen, aangezien dit wordt gedelegeerd aan de klassenlader.

Een softwarebibliotheek is een verzameling gerelateerde objectcode . In de Java-taal zijn bibliotheken meestal verpakt in JAR-bestanden . Bibliotheken kunnen objecten van verschillende typen bevatten. Het belangrijkste type object in een Jar-bestand is een Java-klasse . Een klasse kan worden gezien als een benoemde code-eenheid. De klassenlader is verantwoordelijk voor het lokaliseren van bibliotheken, het lezen van hun inhoud en het laden van de klassen in de bibliotheken. Dit laden gebeurt meestal "op aanvraag", in die zin dat het niet plaatsvindt totdat de klasse door het programma wordt aangeroepen. Een klasse met een bepaalde naam kan slechts één keer worden geladen door een bepaalde klasselader.

Elke Java-klasse moet worden geladen door een klassenlader. Verder kunnen Java- programma's gebruik maken van externe bibliotheken (dat wil zeggen bibliotheken die zijn geschreven en geleverd door iemand anders dan de auteur van het programma) of ze kunnen, althans gedeeltelijk, zijn samengesteld uit een aantal bibliotheken.

Wanneer de JVM wordt gestart, worden drie klassenladers gebruikt:

  1. Bootstrap-klasse lader
  2. Uitbreidingsklasse loader
  3. Systeemklasse-lader

De bootstrap class loader laadt de Java-kernbibliotheken die zich in de <JAVA_HOME>/jre/libdirectory bevinden. Deze klassenlader, die deel uitmaakt van de kern-JVM, is geschreven in native code.

De extensions class loader laadt de code in de extensions directory's ( <JAVA_HOME>/jre/lib/ext, of een andere directory gespecificeerd door de java.ext.dirssystem eigenschap).

De loader van de systeemklasse laadt de code die is gevonden op java.class.path, die is toegewezen aan de CLASSPATH omgevingsvariabele .

Door de gebruiker gedefinieerde klassenladers

De Java-klasselader is geschreven in Java. Het is daarom mogelijk om uw eigen klassenlader te maken zonder de fijnere details van de Java Virtual Machine te begrijpen. Elke Java-klasselader heeft een bovenliggende klasselader, gedefinieerd wanneer een nieuwe klasselader wordt geïnstantieerd of ingesteld op de standaardklasselader van de virtuele machine.

Dit maakt het mogelijk (bijvoorbeeld):

  • om klassen tijdens runtime te laden of te verwijderen (bijvoorbeeld om bibliotheken tijdens runtime dynamisch te laden, zelfs vanaf een HTTP- bron). Dit is een belangrijke functie voor:
  • om de manier te wijzigen waarop de bytecode wordt geladen (het is bijvoorbeeld mogelijk om gecodeerde Java-klasse-bytecode te gebruiken).
  • om de geladen bytecode te wijzigen (bijvoorbeeld voor het in de laadtijd weven van aspecten bij gebruik van aspectgeoriënteerd programmeren ).

Klassenladers in Jakarta EE

Jakarta EE-toepassingsservers (voorheen Java EE en J2EE) laden doorgaans klassen uit een geïmplementeerd WAR- of EAR- archief door een boom met klassenladers, waarbij de toepassing wordt geïsoleerd van andere toepassingen, maar klassen worden gedeeld tussen geïmplementeerde modules. Zogenaamde " servletcontainers " worden meestal geïmplementeerd in termen van meerdere klassenladers.

JAR hel

JAR-hel is een term die lijkt op DLL-hel die wordt gebruikt om alle verschillende manieren te beschrijven waarop het classloading-proces uiteindelijk niet werkt. Er zijn drie manieren waarop de JAR-hel kan optreden:

  • Toevallige aanwezigheid van twee verschillende versies van een bibliotheek die op een systeem zijn geïnstalleerd. Dit wordt door het systeem niet als een fout beschouwd. In plaats daarvan laadt het systeem klassen uit de ene of de andere bibliotheek. Het toevoegen van de nieuwe bibliotheek aan de lijst met beschikbare bibliotheken in plaats van deze te vervangen, kan ertoe leiden dat de toepassing zich nog steeds gedraagt ​​alsof de oude bibliotheek in gebruik is, wat heel goed het geval kan zijn.
  • Meerdere bibliotheken of toepassingen vereisen verschillende versies van bibliotheek foo . Als versies van bibliotheek foo dezelfde klassenamen gebruiken, is er geen manier om de versies van bibliotheek foo met dezelfde klasselader te laden.
  • De meest complexe JAR-helproblemen ontstaan ​​in omstandigheden die profiteren van de volledige complexiteit van het classloading-systeem. Een Java-programma hoeft niet slechts een enkele "platte" klassenlader te gebruiken, maar kan in plaats daarvan zijn samengesteld uit verschillende (potentieel zeer veel) geneste, samenwerkende klassenladers. Klassen die door verschillende klassenladers worden geladen, kunnen op complexe manieren interageren die niet volledig worden begrepen door een ontwikkelaar, wat leidt tot fouten of bugs die moeilijk te analyseren, uit te leggen en op te lossen zijn.

De OSGi Alliance specificeerde (beginnend als JSR 8 in 1998) een modulariteitskader dat tot doel heeft de JAR-hel op te lossen voor huidige en toekomstige VM's in ME, SE en EE, dat algemeen wordt aangenomen. Met behulp van metadata in het JAR- manifest worden JAR-bestanden (bundels genoemd) per pakket bedraad. Bundels kunnen pakketten exporteren, pakketten importeren en pakketten privé houden, en bieden de basisconstructies van modulariteit en afhankelijkheidsbeheer op basis van versies.

Om de JAR Hell-problemen te verhelpen,  werd in 2005 een Java Community Process - JSR 277 - gestart. De resolutie - Java Platform Module System  - was bedoeld om een ​​nieuw distributieformaat, een moduleversieschema en een gemeenschappelijke modulerepository te introduceren (vergelijkbaar met Microsoft .NET 's Global Assembly Cache ). In december 2008 kondigde Sun aan dat JSR 277 in de wacht werd gezet. Het Java-modulesysteem werd later opnieuw opgestart als "project Jigsaw", dat was opgenomen in Java 9 .

Zie ook

voetnoten

Referenties

Externe links