Antwoord

ClassLoader is een speciale component in de JVM die verantwoordelijk is voor het laden van de bytecode van klassen in het geheugen bij hun eerste gebruik. Het maakt het mogelijk om klassen dynamisch te laden vanuit verschillende bronnen (bestandssysteem, netwerk, archief, enzovoort).

Types class loaders:

• Bootstrap ClassLoader — de systeembelader, laad de basisklassen van de JVM (rt.jar).
• Extension ClassLoader — laadt extensies vanaf het pad jre/lib/ext.
• System (Application) ClassLoader — laadt klassen van de applicatie vanaf de classpath.
• Custom ClassLoader — gebruikersbeladers, nuttig voor modulariteit, hot deployment, plugins.

ClassLoader implementeert delegatie: het probeert eerst een klasse te laden met de ouderbelader (parent-first), alleen als dat niet lukt, zoekt het zelf.

Isolatie van klassen: Elke class loader creëert zijn eigen "zichtbaarheid" van klassen. Twee klassen met dezelfde naam, geladen door verschillende loaders, worden als verschillende types binnen de JVM beschouwd.

Voorbeeld van het maken van een eigen loader:

class MyClassLoader extends ClassLoader {
    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        // Jouw code voor het zoeken en laden van bytecode van de klasse
        return super.findClass(name);
    }
}

---

Vragen met een valstrik

Kunnen twee klassen met dezelfde naam, geladen door verschillende loaders, als één klas binnen de JVM worden beschouwd?

Antwoord: Nee! De JVM beschouwt een klasse als uniek op basis van het paar (volledige naam van de klasse, class loader). Daarom worden dezelfde klassen, geladen door verschillende loaders, als verschillend beschouwd.

---

Voorbeelden van echte fouten door onbekendheid met nuances van het onderwerp

---

Verhaal

In een enterprise-applicatie met ondersteuning voor plug-inarchitectuur werden plugins geladen door afzonderlijke class loaders. Dit leidde ertoe dat het proberen om een object van het type interface (PluginInterface) tussen de hoofdapplicatie en de plugin over te dragen een ClassCastException veroorzaakte, omdat dezelfde interface door verschillende loaders was geladen.

---

Verhaal

Bij het gebruik van een aangepaste class loader werd de delegatie naar de ouder loader niet geïmplementeerd. Dit leidde tot herhaaldelijk laden van standaard bibliotheekklassen, wat leidde tot vreemde fouten zoals ClassCastException en LinkageError.

---

Verhaal

In een grote Java EE-server laadden verschillende applicaties hun versies van dezelfde bibliotheek. Verwaarlozing in de configuratie van de loaderketen leidde ertoe dat klassen tussen applicaties elkaar overlappen, wat ooit leidde tot een massive memory leak en crashes door versieconflicten.