Das Siebener-Puzzle

Zum Thema Java 7 gab es bis Januar leider nicht sehr viele konkrete Ansagen von Sun. Daher wurde Mark Reinholds Keynote zum Thema JDK 7 und Modularität bei der Devoxx-Konferenz im winterlichen Antwerpen mit Spannung erwartet. Eingeläutet hatte Mark, der als Principal Engineer bei Sun Microsystems an Java SE und OpenJDK arbeitet, seinen Devoxx-Auftritt mit einer Serie [1], [2], [3], [4] von Blogeinträgen. Sie gipfelte in der Ankündigung eines neuen OpenJDK-Projekts, Jigsaw.

Im Gegensatz zum überambitionierten und von der OSGi-Community als Konkurrenz betrachteten JSR 277, ist Jigsaw der weitaus bescheidenere Entwurf eines simplen Modulsystems für das JDK selbst. Um dem beginnenden Bauchansatz der erwachsen gewordenen JDK zu begegnen, wurden ein paar Mittel erfunden und ausprobiert, vom Pack200 Kompressionsformat in J2SE 5.0 bis zum Java Kernel in Java SE 6 Update 10. Gebracht hat's sicherlich etwas, aber mit jedem Release ist der Umfang des JDK stetig weiter mit den Anforderungen gewachsen. Das macht das JDK auf Dauer etwas unhandlich als Basiskomponente in eingebetteten Systemen oder auf Distributionen: Der verfügbare Platz auf einer Ubuntu-CD oder im Speicher eines Handys ist eng begrenzt und sehr begehrt. Damit das JDK auch in diesem Umfeld seinen angestammten Platz finden und halten kann, muss es eine Möglichkeit geben, es in einzelne Komponenten zu zerlegen, die sich bei Bedarf zu einem vollständigen JDK wie Puzzlestücke von einem internen Modulsystem automatisch verbinden lassen.

Dabei hat man aus den bisherigen Kontroversen um JSR 277 gelernt, und versucht nicht mehr ein eigenes, neues Modulsystem in Java SE 7 zu standardisieren. Die als Ziel für Jigsaw ausgerufene Interoperabilität mit Paketverwaltungssystemen aus der Solaris- und Linux-Welt, sowie der Wunsch, sich den Umstieg auf eine entsprechend angepasste, zukünftige OSGi-Version als Möglichkeit vorzuhalten, würden eine Standardisierung von z.B. Versionierungssemantik über OSGi-, RPM-, dpkg- und IPS-Grenzen hinweg rechtzeitig für JDK 7 unwahrscheinlich erscheinen lassen, wenn überhaupt. Daher legt man mehr Gewicht auf den JSR 294, der aus dem JSR 277 wieder ausgegliedert wird.

JSR 294 definiert die neuen Sprachfeatures für Java SE 7, um Modularität zu unterstützen. In seinem Vortrag auf der Devoxx beschrieb der Spec Lead für die JVM und die Programmiersprache Java, Alex Buckley, einen neuen Entwurf, der die Anpassungen der VM und der Sprache von einem konkreten Modulsystem entkoppelt. Damit entfällt auch zum großen Teil der Streit um die korrekte Versionssemantik und -syntax – die JVM fragt dafür einfach beim Modulsystem nach, indem sie die Modulnamen und Versionsstrings an das darunter liegende System weiterreicht.

Die offensichtliche Frage ist: Warum nicht gleich OSGi nehmen? Die Antwort darauf findet man einerseits in der veränderten Problemstellung – ein Modulsystem, das Java zum Betrieb voraussetzt, lässt sich eher mühselig einsetzen, um das darunter liegende JDK selbst in Komponenten zu zerlegen – und andererseits in der hitzigen Debatte, die um JSR 277 geführt worden ist. Ein Alleingang von Sun mit OSGi für JDK 7, egal ob als Unter- oder als Obermenge des aktuellen OSGi-Standards, würde kein Wohlwollen in der OSGi-Gemeinde finden. Die Problemstellung der Modularität auf den Ebenen über und unter dem JDK wird dank Jigsaw erst einmal voneinander entkoppelt.

Damit bekämen auch die Distributoren von Open-Source-Betriebssystemen eine Chance auf der unteren Ebene mitzureden, auf der sie Anforderungen und Erfahrungen aus der langjährigen Praxis einbringen können, die bisher sowohl im JSR 277 als auch in OSGi untergegangen sind. Unter Linux sind Paketverwaltungssysteme wie RPM und dpkg seit über 15 Jahren Alltag, und wie selbstverständlich für Komponenten in verschiedenen Programmiersprachen nutzbar. Auf dem Weg in eine Welt, in der neben Java auch weitere Programmiersprachen auf der JVM zum täglichen Brot gehören, könnte man sicherlich von diesen Erfahrungen profitieren.

Weitere Puzzlestücke

Das vorläufige Bild von JDK 7 wurde von Mark weiter komplettiert : Closures sind wohl erst einmal aus dem Fokus gerückt, stattdessen ist JSR 308 drin (Annotationen auf Typen). Auch Beans Binding, JSR 295 wird es eher nicht in JDK 7 schaffen – dafür könnte der Weg für JSR 296, Swing Application Framework frei sein. Große Priorität, neben der Modularisierung des JDK, wird auch der verbesserten Unterstützung für dynamische Sprachen auf der JVM eingeräumt, sowie den neuen NIO APIs, die unter anderem endlich eine moderne Schnittstelle zum Dateisystem im java.nio.file-Paket mitbringen. Beide Features haben entsprechende Projekte innerhalb von OpenJDK.

Als weitere JDK-7-Anwärter aus dem Projektumfeld von OpenJDK wurden SCTP und ein neues Projekt für kleine Sprachänderungen genannt. Vor allem das letztere Projekt dürfte sich als interessant für ein breiteres Publikum entpuppen: Es wird von Joe Darcy geführt, der bereits mit seinem OpenJDK-6-Projekt in der Zusammenarbeit mit einer aktiven Open Source Community erprobt ist. Joe hat in seinem Blog das Projekt und die Spielregeln angekündigt, man darf gespannt sein, wie es da weiter geht, und welche neuen Sprachelemente neben JSR 308 außerhalb von Sun kommen werden.

Neue Features außerhalb von Sun sollten auch die XRender Pipeline für Java2D mitbringen – deren Entwickler Clemens Eisserer ist mittlerweile damit beschäftigt, den nativen Code dafür möglichst weit nach Java zu überführen, um noch mehr Performance aus der Hotspot JVM herauszukitzeln – und das nächste Update von Doug Leas JSR 166.

Nouvelle Vague

Beim oben erwähnten SCTP handelt es sich um ein Projekt, um das Stream-Control-Transport-Protokoll zu implementieren. SCTP ist ein alternatives Transportprotokoll, das die Vorzüge aus UDP und TCP vereint. Das dazu gehörige OpenJDK-Projekt wurde im Oktober letzten Jahres gegründet.

Ein Mercurial Repository hat in der Zwischenzeit auch das OpenJDK-6-Projekt bekommen. Damit ist die Migration von Teamware zu Mercurial auch in diesem Bereich endlich abgeschlossen, und die Arbeit an OpenJDK 6 kann nun wesentlich einfacher mit externen Commitern weitergehen. Einen großen Gewinn sollte das vor allem für den Patch-Fluss aus den Linux-Distributionen über IcedTea nach OpenJDK bringen.

Mit dem OpenJDK 6 build 13 hat schließlich ein "ungepatchter" Build von OpenJDK 6 die Feuerprobe auf die Kompatibilität mit Java SE 6 unter Linux bestanden, wie Joe Darcy in einem weiteren Blog berichtet. Damit ist die Integration der dafür notwendigen Patches von Red Hat in OpenJDK 6 abgeschlossen. Red Hat konnte bereits kurz nach der Java One 2008 das erfolgreiche Bestehen der Tests unter Fedora vermelden. Nun wird der Weg für andere Distributoren zu einem freien und kompatiblen Java SE 6 Binary noch einfacher – und auch für Portierungen interessanter. Mal sehen, was die nächsten Monate an Neuigkeiten in diesem Bereich bringen – die Liste der OpenJDK-Community-TCK-Lizenznehmer fängt an zu wachsen und beinhaltet neuerdings auch hybride Implementierungen aus der Klassenbibliothek von OpenJDK und alternativen virtuellen Maschinen.

Links & Literatur

1. http://blogs.sun.com/mr/entry/cool
2. http://blogs.sun.com/mr/entry/massive_monolithic_jdk
3. http://blogs.sun.com/mr/entry/packaging_java_code
4. http://blogs.sun.com/mr/entry/modular_java_platform
5. http://blogs.sun.com/mr/entry/jigsaw
6. http://neilbartlett.name/blog/2008/03/31/no-way-to-run-a-jsr/
7. http://jcp.org/en/jsr/detail?id=277
8. http://java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide/pack200.html
9. http://java.sun.com/javase/6/docs/technotes/guides/jweb/otherFeatures/jre_install.html#kernel
10. http://blogs.sun.com/meetjeet/entry/osgi_vs_jsr_277
11. http://jcp.org/en/jsr/detail?id=294
12. http://java.dzone.com/articles/java-7-update-mark-reinhold-de
13. http://openjdk.java.net/projects/type-annotations
14. http://beansbinding.dev.java.net
15. http://appframework.dev.java.net
16. http://blogs.sun.com/darcy/entry/small_language_changes_jdk_7
17. http://blogs.sun.com/darcy/entry/guidance_measure_language_change_size
18. http://g.oswego.edu/dl/concurrency-interest/
19. http://openjdk.java.net/projects/sctp/
20. http://blogs.sun.com/darcy/entry/openjdk_6_b13_and_jck
21. http://openjdk.java.net/groups/conformance/JckAccess/jck-access.html