Wechseljahre

Anfang Februar fand im winterlich kühlen Brüssel das "Free and Open Source Software Developers European Meeting", kurz FOSDEM statt. Die OpenJDK-Community nutzt diese Konferenz seit Jahren als zentralen Treffpunkt der Entwickler von OpenJDK, GNU/Linux-Distributionen, Forschungsprojekten und anderen freien VM-Implementierungen. Letztere setzen zunehmend auf OpenJDK als Klassenbibliothek. So verkündeten die Entwickler des fast vollständig in Java geschriebenen Open-Source-Betriebssystems JNode pünktlich zur FOSDEM den erfolgreichen Umstieg auf OpenJDK im Unterbau der eigenen Implementierung. Die CACAO VM hat im letzten Jahr ebenfalls einen erfolgreichen Wechsel der Klassenbibliothek in Richtung OpenJDK hinter sich gebracht, genauso wie das IKVM Projekt. Auch JamVM Chefentwickler Robert Laugher dachte bei seinem Vortrag laut darüber nach, den Wechsel auf OpenJDK anzugehen. Ähnliche, mit ersten Patches begleitete Gedankenspiele gibt es bei der JikesRVM.

OpenJDK ist für die nächste Generation der experimentierfreudigen, innovativen Laufzeitumgebungen eine attraktive und vitale Komponente. Für viele Jahre spielte das GNU-Classpath Projekt diese Rolle, das mit dem permeable development Entwicklungsmodell für ein Aufblühen der alternativen VM-Community sorgte und die sozialen Netzwerke schuf, die Open Source Java möglich machten. Eine Wachablösung kündigte sich hier bereits in den letzten Jahren an, nun scheint OpenJDK erfolgreich auch in diese nicht geplante Nebenrolle zu schlüpfen.

Schnellsprech

Die Hauptrolle ist und bleibt die Entwicklung von JDK 7. Dazu gab es von Joe Darcy, dem Projektleiter des Project Coin, einen Vortrag, der auf die Stolperfallen einging und die Komplexität hinter scheinbar einfachen Sprachänderungen wie der Einführung der Aufzählungen mittels Enums. Die notwendigen Änderungen erstreckten sich dabei über die Sprachspezifikation, die Klassenbibliothek, zur JVM-Spezifikation, dem Compiler, der JVM selbst, hin zu Reflection APIs, in die dunklen Ecken der APIs zur Serialization hinein und, last but not least, das javadoc-Tool. Ein strammes Pensum, wenn man bedenkt, wie einfach Workarounds für typsichere Enums in der ersten Ausgabe von Effective Java schienen.

Damit man den auf sich zukommenden Aufwand besser abschätzen kann, hat Joe eine Liste von Kriterien für neue Sprachelemente veröffentlicht sowie ein "Formular", das die wesentlichen Problemstellungen in Kurzform abfragt. Die Hauptkriterien sind einerseits, alltägliche Programmierarbeiten in Java für Entwickler zu erleichtern und andererseits, geplante Änderungen der Plattform zu unterstützen, wie z.B. die Arbeit an der Modularisierung des JDK. Eine Modifikation der Sprache gilt als klein im Sinne von Project Coin, wenn der absehbare Aufwand auf allen drei Hauptachsen (Spezifikation, Testen, Implementierung) klein genug ist, um einen zügigen Fortschritt zu gewährleisten, und die Sprachneuerung nur eine kleine Hürde zu nehmen hat, um von möglichst vielen Java-Entwicklern produktiv genutzt werden zu können. Inzwischen ist die Proposal-Phase vorbei.

Als mögliche Beispiele präsentierte er auf der FOSDEM unter anderem die Idee, die Switch-Anweisung auf Strings zu erweitern, die entsprechenden Code weniger umständlich ausfallen lassen würde, genauso wie die Möglichkeit, mehrere Exceptions in einem catch-Block zu behandeln, häufig duplizierten Code vermeiden würde, und es sehr praktisch wäre, bei Konstruktoren auf eine explizite Wiederholung der selben Typparameter auf beiden Seiten einer Zuweisung verzichten zu können. Das sind für sich alleine genommen keine weltbewegenden Änderungen, aber, ähnlich wie die erweiterte for-Schleife in Java 1.5, auf die kleinen Verbesserungen der Produktivität im alltäglichen Einsatz bedacht.

Schöner patchen

Produktivität ist ein gutes Stichwort. Damit die Arbeit in einem Open-Source-Projekt gut laufen kann, braucht man entsprechende Infrastruktur für die Community. Lange hatte das OpenJDK-6-Projekt diese Infrastruktur nicht wirklich. Der Grund dafür war ein ganz prosaischer: Bei Sun werden die Java SE 6 Updates noch mit den internen Werkzeugen wie Teamware verwaltet, während OpenJDK auf das offene Revisionskontrollsystem Mercurial setzt. Obwohl der Java-SE-6-Codezweig nicht Teil von OpenJDK ist, wollten die Sun-Entwickler die Möglichkeit haben, Patches aus Java SE 6 in OpenJDK 6 zu übernehmen, daher benutzten sie ebenfalls Teamware. Nach dem Release von Java SE 6u10 waren die ganz großen Wartungsarbeiten an Java SE 6 erst einmal erledigt, und damit war der Weg frei für OpenJDK 6, den Umstieg auf Mercurial nachzuvollziehen, und externen Committern Schreibzugriff auf die Repositories von OpenJDK 6 zu geben.

Kelly O'Hair gab diesen Umstieg im Februar bekannt. Für weitere Verbesserungen der Infrastruktur sorgten Brad Wetmore, der eine Bugzilla-Instanz für OpenJDK bereitstellte, sowie Tim Bell, der einen Code Review Server entwickelte. Der Bugtracker Bugzilla ist bei großen Open-Source-Projekten wie Eclipse im Einsatz. Im Gegensatz zu vergleichbaren Lösungen ist er Open-Source, und damit für ein Projekt wie OpenJDK wesentlich attraktiver – auch durch den anstehenden Wechsel von Projekten wie OpenSolaris von Sun-interner Bugtracking-Infrastruktur auf Bugzilla. Als erster Schritt wird er bei OpenJDK eingesetzt, um Patches von externen Entwicklern zu sammeln und zu integrieren. In weiteren Stufen soll der OpenJDK Bugzilla ausgebaut und später an die internen Lösungen wie bugs.sun.com angebunden werden können.

Patches sind nur das halbe Leben – die andere Hälfte sind Code Reviews. Bei den meisten Projekten innerhalb von OpenJDK haben sie einen strikten Review-Prozess zu durchlaufen, bei dem so lange an den Änderungsvorschlägen gefeilt wird, bis Reviewer und Entwickler mit dem Ergebnis zufrieden sind. Das mag auf den ersten Blick etwas mühselig erscheinen – ist aber ein bewährter Weg, um komplexe Software, wie das JDK und JVM, zu entwickeln, ohne Abstriche bei der Wartbarkeit und der Qualität des Codes hinnehmen zu müssen. Mit Review-intensiven Prozessen ist z.B. auch das Firefox-Projekt sehr gut gefahren. Damit Reviews etwas produktiver sind, stellt OpenJDK seinen Committern einen Code Review Server bereit, auf dem Patches im Webrev-Format bereitgestellt und begutachtet werden können, um auf den entsprechenden Mailinglisten gelobt oder mit konstruktiver Kritik konfrontiert zu werden.

Paketdienst

Nachdem OpenJDK 6 in so ziemlich allen großen GNU/Linux-Distributionen angekommen ist, ließ es sich auch das Releaseteam der aktuellen Version von Debian, "Lenny", nicht nehmen, stolz darauf hinzuweisen, dass Lenny OpenJDK 6 von Haus aus mitbringt. Aber es gibt auch über Linux hinaus eine Menge von Open-Source-Betriebssystemen, bei denen OpenJDK „out of the box“ ein ganz nettes Feature wäre. FreeBSD zum Beispiel. Die BSD-Portierung in OpenJDK basiert auf OpenJDK 7 und ist damit für BSD-Distributionen im Moment noch nicht so attraktiv, wie es eine Portierung von OpenJDK 6 wäre. Das ließe sich durch einen Backport der Entwicklungsarbeit des BSD-Teams beheben, und genau das hat Brian Gardner auch gemacht. Dank seiner Patches gibt es nun ein OpenJDK-6-Paket in der FreeBSD Ports Collection, und damit ist OpenJDK 6 unter FreeBSD ab jetzt nur ein pkg_add weit entfernt. Abzuwarten bleibt noch, wie schnell sich diese OpenJDK-6-Portierung auf den Weg nach NetBSD, OpenBSD, DragonFly BSD und in ähnliche Betriebssysteme macht. Für Fans von BSD-artigen Betriebssystemen gilt: Immer mal wieder in den Paket-Repositories der eigenen Distribution nachschauen, und falls sich bis zum Erscheinen dieser Kolumne nichts getan hat, einfach mal selbst Hand anlegen – so, wie Brian es vorgemacht hat.

Diese Kolumne erschien im Java Magazin 5.09

Links & Literatur

1. http://jnode.org/
2. http://jnode.org/node/2879
3. http://cacaovm.org/
4. http://www.ikvm.net/
5. http://jamvm.sourceforge.net/
6. http://jikesrvm.org/
7. http://public.smi.ethz.ch/blog/2006/01/25/permeable-development/
8. http://blogs.sun.com/darcy/resource/FOSDEM/FOSDEM-2009-darcy-ProjectCoin.pdf
9. http://java.sun.com/developer/Books/shiftintojava/page1.html#replaceenums
10. http://blogs.sun.com/darcy/date/20081223
11. http://blogs.sun.com/darcy/date/20090127
12. http://en.wikipedia.org/wiki/TeamWare
13. http://www.selenic.com/mercurial/wiki/
14. http://blogs.sun.com/darcy/date/20090209
15. http://blogs.sun.com/wetmore/entry/extra_extra_read_all_about
16. http://cr.openjdk.java.net/
17. http://openjdk.java.net/groups/web/bugzilla.html
18. http://blogs.sun.com/jcc/entry/webrev_for_openjdk_a_code
19. http://www.debian.org/releases/lenny/amd64/release-notes/ch-whats-new.de.html
20. http://robilad.livejournal.com/44589.html