Im letzten Jahr war die große Überraschung der Devoxx die Ankündigung des Project Jigsaw, in dem die Werkzeuge zur Modularisierung des JDK entwickelt und angewandt werden. Ein Jahr danach zog Mark Reinhold, Principal Engineer bei Sun Microsystems, bei seinem Devoxx Vortrag eine erste Bilanz.

Mit Skalpell und Kettensäge

Eines der Ziele beim Einsatz von Jigsaw ist es, das JDK bis in die untersten Ebenen hinein in kleinste Module aufteilen zu können um es auch für kleinste Geräte fit zu machen. Dafür benötigt man ein Modulsystem, das so wenig von der Java Plattform wie nur möglich braucht, und auch nur die Features mitbringt, die für die Modularisierung der Millionen von Zeilen des über ein Jahrzehnt organisch gewachsenem Code notwendig sind. Ein klassisches Problem dabei ist die bestehende Java SE API – die bereits vorhandenen Klassen und Methoden werden von Millionen von Java Entwicklern genutzt, und lassen sich nicht mehr in eine andere, filigranere Paketstruktur umbauen ohne vermeidbare Probleme zu bereiten.

Daher ist es sinnvoll für ein bestehendes Projekt mit festen Schnittstellen wie dem JDK, die architektonische Sicht auf abstrakte, logische Module möglichst einfach auf bestehende konkrete Paket- und Klassenstrukturen abbilden zu können. Das führt zur Notwendigkeit M logische Module ohne großen Aufwand auf N Pakete abbilden können zu müssen, also Klassen aus einzelnen Paketen ggf. auf mehrere, separate logische Module zu verteilen, und den in der OSGi Community nicht sehr beliebten 'split packages'. Dafür stellt sich bei Jigsaw die Frage der Unterstützung dynamischer Module, und eines damit einhergehenden Life Cycle gar nicht – aus der Sicht von Applikationen ist das JDK eine Sammlung von statischen Komponenten.

So unterscheidet sich Jigsaw einerseits in der Zielsetzung und Philosophie von OSGi, anderseits aber auch im Detail. Jigsaw schreibt nicht vor, ob die Version eines Moduls drei, vier, fünf, oder mehr Stellen haben muss – oder welche Bedeutung sich hinter der Struktur eines Versionsstrings zu verbergen hat. Verschiedene Organisationen haben in diesem Bereich unterschiedliche Konventionen. Über deren Sinn und Unsinn kann man streiten, an ihrer Existenz ändert das jedoch nichts.

Statt darauf zu pochen, dass die Welt sich auf eine Konvention einigt, und diese auch fehlerfrei umsetzt, beschränkt sich Jigsaw absichtlich auf die grundlegenden Eigenschaften von Versionen: Identität, um Abhängigkeit von einem bestimmten Modul in einer bestimmten Version auszudrücken, und eine Ordnungsrelation über die zulässigen Versionsstrings eines Moduls, um zeitlich beschränkte Abhängigkeiten ausdrücken zu können. Die letztere ist durch einen lexikographischen Vergleich über die einzelnen Komponenten des Versionsstrings gegeben. Wie viele Komponenten benutzt, wie und warum sie verändert werden bleibt ganz dem Modulentwickler überlassen. Dieses sehr liberale, sehr flexible und an sich sehr einfache Versionsschema hat Jigsaw weitgehend von Debian GNU/Linux übernommen.

Von dem sehr komplexen Graph der Abhängigkeiten der über 50 ursprünglichen Komponenten im JDK, ist nach ausgiebigem Refactoring hinter den Kulissen der Implementierung der Klassenbibliothek, sowie der Arbeit mit Jigsaw ein wesentlich kleinerer Teil übrig – vorläufig sind es noch 27 'Knoten', mit insgesamt etwa 35 'Kanten', wenn man die optionalen Abhängigkeiten ausblendet.

Die Arbeit an Jigsaw und der Modularisierung der Klassenbibliothek ist noch nicht abgeschlossen. Für Entwickler, die sich für das Projekt und das modularisierte JDK 7 interessieren, hat Mark Reinhold experimentelle, auf JDK 7 Milestone 5 basierende Pakete für Ubuntu auf der Projektseite bereit gestellt.

Spielverlängerung

Ebenfalls auf der Devoxx stellte Mark Reinhold den aktuellen Stand der Dinge bei JDK 7 vor. Das entsprechende OpenJDK Projekt hat mit dem Build 76 den fünften Milestone abgeschlossen. Nicht alle der geplanten Features haben den Sprung in diesen Milestone geschafft – daher wurden drei weitere Milestones hinzugefügt. Die dadurch gewonnene Zeit liesse sich, neben der Arbeit an den noch fehlenden Features, auch für anderes Nutzen. Joe Darcy deutete auf der Mailingliste von Project Coin an, dass möglicherweise nun die Zeit reicht auch multi-catch, d.h. die Fähigkeit, mehrere Exceptions auf einmal abzufangen, in die von Project Coin implementierten kleineren Sprachverbesserungen aufzunehmen.

Zurück in die Zukunft

Die größte Überraschung der Devoxx war jedoch die Ankündigung, dass es an der Zeit ist, wieder das Thema Closures aufzugreifen. In den vergangenen Jahren wurde kaum ein anderes Thema so emotional debattiert, wie Closures – einerseits zwischen Entwicklern, die sich fragten ob dieses Sprachfeature überhaupt in die Programmiersprache Java passt, und Entwicklern, die sich ein zukünftiges Java ohne Closures gar nicht mehr vorstellen mochten, und vor allem innerhalb der letzteren Gruppe von Entwicklern, welcher der verschiedenen konkurrierenden Vorschläge wie Closures in Java zu machen sind, nun wirklich der überlegene sei.

In seinem Blogpost zum Thema schildert er die Motivation dahinter. In einer Zeit, in der Mehrkernprozessoren an der Tagesordnung sind, ist die Entwicklung von gut skalierenden, parallelen Programmen in Java für die meisten Entwickler immer noch ein sehr mühsames Geschäft. Die Einbindung des Fork/Join Frameworks im JDK 7 Milestone 5 ist ein weiterer Schritt um den Entwicklern diese Aufgabe etwas einfacher zu machen. Die Benutzung von solchen Frameworks erfordert jedoch ein gewisses Maß an Erfahrung und Feinjustierung. Ein weiterer Schritt zur besseren Benutzbarkeit für 'normale' Entwickler wären APIs wie ParallelArray, die automatisch Operationen auf das Fork/Join Framework abbilden. Dieses Feature ist jedoch nicht für JDK 7 geplant - der Einsatz von ParallelArray erfordert selbst für einfache Probleme eine Menge Code der vor allem da ist, um den Compiler glücklich zu machen. Code der mit Closures in Java nicht notwendig wäre.

Nachdem mit BGGA, CICE und FCM verschiedene Vorschläge den Rahmen des Möglichen abgesteckt haben, und die Community einiges aus dieser Arbeit über Sinn und Möglichkeiten von Closures in Java gelernt hat, ist es deshalb an der Zeit eine einfache Form der Closures in den Angriff zu nehmen. Neben einer Syntax, bräuchte man dafür Funktionstypen, damit sich Closures im Typsystem der Sprache integrieren lassen. Dazu kommen noch Closure Conversion, damit Closures dort genutzt werden können, wo abstrakte Klassen und Interfaces mit einer einzigen Methode erwartet werden, und Extension Methods, mit denen sich Closure-verarbeitende Methoden in bestehende APIs integrieren lassen würden, ohne deren Kompatibilität zu beeinträchtigen.

Sun wird im Rahmen von JDK 7 die Arbeit an den oben skizzierten einfachen Closures aufnehmen, und lädt, wie in OpenJDK üblich, die Community ein, sich an dem Projekt zu beteiligen. Sollte die Arbeit an diesem Projekt Früchte tragen, so würde sie später von einem eigenen JSR begleitet werden, der dann von Sun als eine Komponente eines zukünftigen Java-7-JSRs vorgeschlagen werden würde.

Testspiel

Von dem bereits mehrfach erwähnten JDK 7 Milestone 5 gibt es natürlich auch Downloads zum Testen für die üblichen Plattformen. Mehr Spaß hat man jedoch wenn man über die Feiertage selbst die Hand an den OpenJDK Quelltext legt. Für den schnellen Build zwischendurch gibt es vom Kelly O'Hair ein paar Tipps für Neueinsteiger. Viel Vergnügen!

Links & Literatur

1. http://openjdk.java.net/projects/jigsaw/
2. http://www.dzone.com/links/mark_reinhold_on_jigsaw_live_notes_from_devoxx.html
3. http://eclipsesource.com/blogs/2009/07/14/why-i-cant-recommend-using-import-package/
4. http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
5. http://www.mobypicture.com/user/surial/view/5671487
6. http://www.mobypicture.com/user/surial/view/5671503
7. http://www.infoq.com/news/2009/11/jdk7m5
8. http://openjdk.java.net/projects/jdk7/milestones/
9. http://en.wikipedia.org/wiki/Closure_(computer_science)
10. http://www.ibm.com/developerworks/java/library/j-jtp04247.html
11. http://blogs.sun.com/mr/entry/closures
12. http://www.ibm.com/developerworks/java/library/j-jtp03048.html
13. http://tronicek.blogspot.com/2007/12/function-types.html
14. http://tronicek.blogspot.com/2007/12/closure-conversion.html
15. http://digital-sushi.org/entry/declaration-site-extension-methods/
16. http://blogs.sun.com/mr/entry/jdk7_m5
17. http://openjdk.java.net/groups/build/
18. http://blogs.sun.com/kto/entry/faster_openjdk_build_tricks