GNU Classpath - Einer für alle, alle für einen

JNode

Der Java New Operation System Design Effort (JNode) entwickelt ein komplettes Betriebssystem in Java (mit einem kleinen Teil in Assembler). Das Projekt von Ewout Prangsma ist seit 2003 in der Entwicklung und setzt auf GNU Classpath als Klassenbibliothek. Da es in JNode kein natives Interface geben wird, treiben dessen Entwickler sehr die Ausarbeitung unserer Schnittstelle zur virtuellen Maschine voran, was schlußendlich allen Projekten zugute kommt.

Auf der Homepage von JNode, die auch gleichzeitig Diskussionsforum ist, kann man sich Design- und Anleitungsdokumente ansehen oder einen Blick auf die Screenshots werfen. Snapshots werden alle paar Monate veröffentlicht und können zum Booten von CD verwendet werden. Alternativ kann man zum Ausprobieren auch einen der gängigen Emulatoren verwenden.

Kaffe

Kaffe kann am ehesten als ein Ersatz für das JDK angesehen werden, da es die gleiche Verzeichnisstruktur besitzt und Bibliotheken wie JacORB und Tritonus mitbringt, um das Feature-Angebot zu komplettieren. Die Kaffe VM wird als das NetBSD unter den virtuellen Maschinen bezeichnet, denn sie läuft bis jetzt auf 50 Plattformen. Daneben gibt es Dutzende Portierungen (z.B. WinCE/NT, Plan9, MS DOS, BEOS, MiNT), die noch nicht in Kaffe aufgenommen worden sind, und jede Menge Forks, die meist für wissenschaftliche Zwecke angelegt wurden.

Im Fork »JanosVM« befindet sich zum Beispiel schon eine funktionierende Implementierung der Isolation API, welche auch als JSR-121 bekannt ist. Diese Technologie ist bei Sun unter dem Namen Barcelona in der Entwicklung. Wer sich dafür interessiert, dem sei dieser Artikel empfohlen.

Die Kaffe-Homepage gibt leider ganz und gar nicht wieder, in welchem Tempo die Arbeiten an der Software stattfinden. Zum Glück hat sich das Kaffe-Team kürzlich mit dem Release der Version 1.1.5 zurückgemeldet. Neben dem obligatorischen Patch-Austausch mit Classpath wird weiterhin an den Interna sowie dem Konstruktionssystem geschliffen. Die zukünftige Entwicklung von Kaffe sieht unter anderem einen neuen JIT-Compiler für RISC-Maschinen und eine Anbindung an GCJs binary-compatibility ABI vor. Letzteres wird es ermöglichen, die von GCJ in native Bibliotheken kompilierten Klassen auch von Kaffe aus zu benutzen.

GCJ

Der GNU-Compiler for Java (GCJ) ist Teil der GNU Compiler Collection (GCC) und hat eine ähnlich lange Geschichte wie Kaffe. GCJ besteht aus dem eigentlichen Compiler, einem Interpreter (Ersatz für das 'java'-Programm), einigen Tools (Ersatz für rmiregistry etc.) und der Klassenbibliothek mit dem Namen libgcj. Der Compiler geht den traditionellen Weg und kompiliert genau wie bei C, C++, Pascal usw. Java-Quellcode in ein natives Binary. Natürlich kann GCJ aus Kompatibilitätsgründen auch Bytecode erzeugen. Mit Hilfe des gcjbuilder genannten Plugins für Eclipse kann der Compiler direkt aus der IDE angesprochen werden, wodurch die Erstellung einer nativ kompilierten Java-Bibliothek zum Kinderspiel wird.

Wer sich schon immer bestraft gefühlt hat, wenn er mittels JNI C und Java mischen wollte, dem empfehle ich unbedingt einen Blick auf CNI. Das Common Native Interface steht für eine qualfreie Verbindung zwischen Java und C++ und unterscheidet sich deutlich in seiner Verwendung.

Zur Demonstration dieser Technik habe ich ein kleines Beispiel aus der GCJ-Dokumentation entnommen. Java-Entwickler werden sofort die nächste Zeile C++-Quellcode verstehen:

java::util::Hashtable *ht = new java::util::Hashtable(120);

Zur Abschreckung ist hier die äquivalente Anweisungsfolge mit JNI (fairerweise unter Verwendung der C++-Version):

jclass cls = env->FindClass("java/util/Hashtable");
jmethodID mid = env->GetMethodID(cls, "<init>", "(I)V");
jobject ht = env->NewObject(obj, mid, 120);

Ob diese Schreibweise zum regen Gebrauch von JNI einlädt, kann jeder für sich entscheiden.

GCJ hat bei der zukünftigen Verbreitung einen Heimvorteil: GCC ist auf sehr vielen Betriebssystemen zu Hause und die Erstellung einer Installation mit integrierter Java-Unterstützung ist ein Kinderspiel.

Apache Harmony

Noch wurde keine Zeile Quellcode (Stand Juli 2005) geschrieben und trotzdem hat es einen Presserummel gegeben, der seinesgleichen sucht. Apache Harmony wird einmal eine komplett J2SE 5.0-kompatible Java-VM sein, die zu den Bedingungen der Apache Software License 2.0 angeboten wird - was also ziemlich liberal ist.

Wenn die Gespräche weiterhin so gut laufen, dann ist es sehr wahrscheinlich, dass Harmony sich bei der Klassenbibliothek auf GNU Classpath stützt.

Zur Architektur lässt sich momentan noch gar nichts sagen, da diese Fragen gerade geklärt werden. Im Gespräch ist jedoch die Übernahme von Quellcode aus einer existierenden VM (JamVM und JCVM wurden hier genannt).

Momentan gibt es von Harmony also nicht mehr zu sehen als eine Mailingliste und eine Projektseite. Interessierte sind weiterhin eingeladen, sich an den Diskussionen zu beteiligen.

Da es bei der Ankündigung des Projektes zu einem Missgeschick gekommen ist, möchte ich nochmal erwähnen, dass an Harmony auch Entwickler von GNU Classpath, GCJ und Kaffe beteiligt sind. Da alle mehr oder weniger mit ihren eigenen Projekten ausgelastet sind, besteht ihr vorrangiges Interesse darin, den Newcomern bei Harmony mit technischem Know-How beiseite zu stehen.

JCVM

Eine recht exotische VM wird von Archie Cobbs geschrieben: JCVM. Besonderheit ist, dass sie Java-Bytecode nach C-Quellcode (!) übersetzt, um diesen anschließend mit dem GCC zu kompilieren und auszuführen. Sie kann aber auch ganz normal Bytecode interpretieren und ein gemischter Betriebsmodus ist ebenfalls vorhanden. Zwar ist JCVM mehr eine Experimentialplattform, jedoch wurde sie im Laufe der Gespräche um Apache Harmony schon als potentielles Basisprojekt gehandelt.

Jikes RVM

Ein Forscherteam der IBM hat mit der Jikes Research Virtual Machine eine sehr interessante Entwicklung hervorgebracht: JikesRVM ist im Kern selbst in Java geschrieben und braucht daher eine andere VM wie Kaffe für den Bootstrap. Außerdem optimiert JikesRVM im Verborgenen die Programmausführung auf Java-Ebene mit Hilfe von nicht standardisierten Spracherweiterungen. Sprachpuristen brauchen aber nichts zu befürchten: Die Erweiterungen sind VM-intern und sind vergleichbar mit Optimierungen, die andere JVMs mit Hilfe von just-in-time Compilern erreichen.