Ich weiß nicht ob das typisch für mich ist, dass ich das neue Jahr mit einem Rant einleite, aber zeitlich ist es jedenfalls nicht beabsichtigt. Ich wasche meine Hände in Unschuld. Zunächst also ein frohes neues Jahr. Die tollen, freundlichen Beiträge kommen alle noch die Tage. Wieder einmal habe ich die Hoffnung, dass dieser Artikel all jenen hilft, die mit einem ähnlichen Problem konfrontiert werden. Das Programmiererleben ist sicherlich vieles, aber gewiss nicht einfach.
Vergangene Woche war ich in der Situation eine portable Version einer Solaris JVM (Java Virtual Machine) aktualisieren zu dürfen. Die bisherige Version des JDK6 war leider veraltet und brachte regelmäßig Segmentation Faults im Dauerbetrieb zustande. Ein neueres Update (1.6.0 Update 38) sollte hoffentlich stabiler laufen. Mit einer portablen Version ist eine Java-Installation gemeint, die man einfach auf dem Zielsystem in ein Verzeichnis seiner Wahl entpackt und die sofort (und vor allem ohne betriebssystemabhängige Installation) lauffähig ist. Aus diesem Grund wollte ich mir eine solche Version von Oracle herunterladen. Das war aber schon das erste Problem: Oracle ist nämlich ziemlich scheiße.
Oracle bietet (jedenfalls für Java 6) keine portablen JDKs zum Entpacken an – nur Installer. Da ich auf dem Zielsystem aber keine Installationsprogramme ausführen kann/darf/will, ist das selbstverständlich keine Alternative, zumal ich ja wusste, dass Java problemlos portabel ausführbar ist. Eine Installation ist daher gar nicht nötig. Kurzerhand musste ich also kreativ werden und basteln. Ich wollte den doofen Installer umgehen und die Dateien von Hand extrahieren. Das war gar nicht so schwierig wie ich dachte. Mein Werk wollte ich im Vorbeigehen kurz an einer Client-Anwendung testen, als beim Starten der JVM eine wilde Fehlermeldung erschien:
Error occurred during initialization of VM
java/lang/NoClassDefFoundError: java/lang/Object
Soso, sehr interessant. Die JVM kann die Klasse java.lang.Object nicht finden. Wenn diese Klasse fehlt, dann fehlt praktisch alles. Ein freundliches Google teilte mir mit, dass es vermutlich mit einer fehlenden Datei rt.jar im Verzeichnis /jre/lib/ zusammenhängt. Tatsächlich, diese Datei gab es dort nicht. Ist Oracle wirklich so bescheuert und liefert ein unvollständiges, nicht lauffähiges JDK aus? Ist das die Strafe dafür, dass ich den Installer übergangen habe?
Ist es. Denn der Installer hat zudem die Aufgabe, die rt.jar aus einer gepackten Datei namens rt.pack auszupacken, und diverse weitere Dateien:
./lib/tools.pack
./jre/lib/charsets.pack
./jre/lib/jsse.pack
./jre/lib/deploy.pack
./jre/lib/javaws.pack
./jre/lib/plugin.pack
./jre/lib/rt.pack
./jre/lib/ext/localedata.pack
Warum das so ist, weiß nur der Teufel. Platzersparnis bringt es gegenüber dem umliegenden Archiv keine. Es ist wahrscheinlich reine Schikane. Manche behaupten auch, das wäre ein Mechanismus, um sicherzustellen, dass niemand den Installer umgeht, da dieser ja zum Akzeptieren der AGB auffordert. Zum Glück gibt es die mitgelieferten Java-Tools pack200 und unpack200. Mit deren Hilfe kann man die JAR-Dateien aus den PACK-Dateien befreien – sogar über verschiedene Betriebssysteme hinweg. Und dann klappt das auch wieder mit der JVM.
Seit diesem Tag hasse ich Oracle wieder ein bisschen mehr, und ich bin ein bisschen weiser geworden. In meinen Augen eine echte Schweinerei. Portable Versionen sind super und hinterlassen weniger Spuren. Wenn man weiß was man tut, und wenn man in der Lage ist, sich selbst um die richtigen Pfadangaben zu kümmern, dann hat ein portables Java viele Vorteile, vor allem wenn man viele homogene Systeme unter seiner Obhut hat.
Quellen:
http://www.cynosurex.com/Forums/DisplayComments.php?file=Java/Finding_rt.jar_in_JRE_5.0_Update_9
http://tntit.blogspot.de/2012/04/linux-jdk-6-installation-hard-way.html
http://turbolinux.org/2011/05/error-occurred-during-initialization-of-vm-javalangnoclassdeffounderror-javalangobject/
http://stackoverflow.com/questions/1619662/where-can-i-get-the-latest-jre-jdk-as-a-zip-file-i-mean-no-exe-installer