Fragen? Antworten! Siehe auch: Alternativlos
Mein Kumpel Kris hat das mal bei Heise ausführlich erklärt.
Und tatsächlich ist die Sache sogar noch verkackter als ich sie zu verstehen geglaubt hatte.
Besonders witzig bei Kris' Ausführungen finde ich, dass er für seine jahrzehntelage Arbeit in der PHP-Community bekannt ist, und dieses verkackte Classloader-Konzept, zur Laufzeit Code nachladen zu wollen, ist auch eine glorreiche PHP-Innovation, die dort allerdings Autoloader heißt.
Dass das möglicherweise grundsätzlich eine völlig verkackte Idee ist, zur Laufzeit Code nachzuladen, ist nicht nur den Founding Fathers von Java nicht gekommen.
Auch in C und C++ gibt es ein API, mit dem man Shared Library nachladen kann, heißt dlopen oder LoadLibrary, und wird für Plugins verwendet. Und auch da haben viele Leute noch nicht verstanden, dass das Plugin dann dieselben Zugriffsrechte hat wie das Programm, in dessen Kontext es ausgeführt wird.
Oh und lasst mich bei der Gelegenheit einen kleinen Schwank erzählen. Kris macht sich in dem Artikel darüber lustig, dass Java-"Anwendungen" heutzutage immer mit der genauen JRE-Version im Paket ausgeliefert werden, die man braucht, um sie auszuführen. Ich hatte mal bei einem Kunde die Gelegenheit, in eine als "Appliance" ausgelieferte Enterprise-Java-"Anwendung" reinzugucken, und die kam mit drei verschiedenen JREs für verschiedene Teile der "Anwendung". Es ist da draußen also noch krasser verkackt als Kris es hier ausspricht.
Ich empfehle ausdrücklich, nicht nur Seite 1 zu lesen. Die ganzen wunderbaren Money-Quotes sind auf Seite 2.
Der wichtigste Punkt an diesem wunderschönen Rant ist jedenfalls, und das sollte ihr auf jeden Fall mit heimnehmen hier: Das war kein Bug im Sinne von "ein Programmierer hat falschen Code hingeschrieben". Der Code war da vorsätzlich, absichtlich, und hat genau das getan, wofür er gedacht war.
Es war, könnte man sagen, einer der seltenen Momente, wo Java-Code genau das getan hat, wofür er gedacht war. Stressarm und flexibel.