JDK 7 – we’re losing our advantage over other platforms and the main reason is lack of a modularity.

Es ist quasi offiziell und die Welt scheint sich damit zu arrangieren – Java 7 wird 2011 endgültig erscheinen.
Wurde anfangs noch über ein reduziertes Release JDK7 als sogenannter Plan B diskutiert, gewinnt dieser wenige Tage später auf der Java One das offizelle Oracle Commitment.
Die neue Java Roadmap glänzt kurze Zeit später auch durch das Bekenntnis von IBM zur gemeinsamen Entwicklung von JDK 7 im OpenJDK Project.
Doch während in der Entwicklergemeinde noch darüber gestritten wird ob ein “schneller Release von Java 7” im nächsten Jahr und die Verschiebung einiger offener Fragen auf Java 8/9 nun das Ende der Welt sind oder einfach nur Java als das “COBOL des neuen Jahrtausends” zementieren, entwickelt sich für mich ein Detail zum echten Problem.
Denn während ich Cay Horstmanns Sicht teile, daß das wahre Problem von Java nicht die mangelhafte Innovation sondern die mangelnde Pflege der existierenden Bibliotheken ist, fürchte ich für das Thema Modularisierung in Java weitaus Schlimmeres. Im Gegensatz zu vielen Bibliotheken des JDK war die Frage nach dem Ausweg aus der sprichwörtlichen “JAR-Hell” immer im Fokus der Diskussion.
Die Definition von Bausteinen die größer als eine Klasse und kleiner als eine komplette Anwendung sind, sowie die Herstellung und Freigabe von Anwendungen aus derartigen Bausteinen sind ein immer wiederkehrendes Thema des Enterprise Java. Beginnend mit J2EE-Serverdeployerextensions durch JMX , über mavenbasierte Buildmanagementlösungen und Portlets bis zu hin OSGi-Plugins wurden im letzten Jahrzehnt vermutlich hunderte mehr oder weniger elaborierte Ideen zur Umsetzung dieses Traums in Java Enterprise Servern geboren.
Der JSR 294 “Improved Modularity Support in the JavaTM Programming Language”, der vor fast 3 Jahren einen konsensfähigen Standard setzen sollte, gehört nun zu den auf Java 8 verschobenen Problemen. Rein formal ist JSR 294 seit 10 Monaten inactive und will seiher einen EDR produzieren.

Die Referenzimplementierung Jigsaw sollte nach damaligen Planungen Bestandteil der JDK Modularisierung sein:

“JDK modularization uses the Jigsaw module system.”

Dabei wurde Jigsaw als implementierungsspezifischer Bestandteil des JDK betrachtet ähnlich dem Classpath zu dem es ebenfalls keinen JSR gibt:
“In addition to implementing JSRs, JDK7 will also have implementation-specific features, such as

a) the classpath (never part of any JSR) and

b) the Jigsaw module system”

Unglücklicherweise schweigen sich die offiziellen Jigsaw-Blogger Spec.Lead Alex Buckley und OSGi Fürsprecher Neil Bartlett zur Zukunft von Jigsaw aus und Neil diskutiert sogar die Rolle des JCP im ganzen.
Leider gibt es auch von Seiten der OSGi Community wenig Informationen zur zukünftigen Lösung der Probleme .
Da OSGi-Evangelist Peter Kriens schon früher die Unsitte eines “Spec. Designs by Blog” kritisierte, erwarte ich von ihm kaum öffentliche Kommentare zu seinen beiden hoch interessanten JSR 294-Vorschlägen zu nested Modules und einem Simple Module System.
Hier droht leider durch die Verschiebung eine erneute Debatte um  JSR 294 und den verabschiedeten JSR 291 (OSGi 4.1), die der Java Plattform in heutigen Betriebs- und Entwicklungsszenarien Fragen hinterläßt, wo der Wettbewerb Antworten gibt.

Wie immer gelingt es dabei Peter Kriens die Tragweite des Problems in Prosa zu kleiden:

“Java is still a tremendous platform but we’re losing our advantage over other platforms and the main reason is lack of a modularity.” [1]

Short URL for this post: http://wp.me/p4nxik-gT
This entry was posted in Java Basics, Java EE and tagged , , . Bookmark the permalink.

One Response to JDK 7 – we’re losing our advantage over other platforms and the main reason is lack of a modularity.

  1. Pingback: There’s not a moment to lose? Jigsaw postponed… forever? | techscouting through the java news

Comments are closed.