Future of Java

In der Keynote erzählt Rod Johnson was über die Zukunft von Enterprise Java. In seiner typisch amerikanischen Art führt er erst mal aus, dass Java nicht mehr sexy ist: "No one will date a Java developer". Ruby sei doch so viel sexier für Web development. Ist natürlich nicht so, sonst stände Johnson ja nicht hier, sondern würde Ruby machen. Also, noch viel amerikanischer: Wir ziehen erst mal Statistiken raus - indeed.com job trends gibt ja die nötigen Daten ohne große Arbeit. Also der Vergleich mit Ruby, mit dot.net, alles in bunten Bildern. Fazit: Damit Java-Entwickler weiter gedated werden, muss sich Java ändern. Mal schauen, was Johnson als six plus two predictions präsentiert.

Aber zuerst mal zu den Faktoren, die Änderungen notwendig machen: Zuerst mal ist da die "productivity challenge" - dass man mit Ruby on Rails schneller ist in der Entwicklung von bestimmten Web-Applikationen ist als mit Java hat sich nun schon rumgesprochen. Der Punkt daran ist, dass die Java community an den "low hanging fruits" vorbeispringt. Warum also immer Rakentenphysik, wenn's auch einfach geht. Si!

Der zweite Grund für notwendige Änderungen ist einfach das Alter von Java EE. Java ist einfach nicht mehr schlank, weil sich mittlerweile eine Menge "baggage" angesammelt hat. Gut, ich hätte zwar "garbage" genommen, aber der Effekt ist der gleiche: Man muss das System wieder aufräumen, den Frühjahrsputz machen. Johnson sieht in Java EE 6 genau den Versuch, die Java Plattform auf Vordermann zu bringen. Die beiden Idees hinter Java EE 6 sind Extensibility und Profiles (steht auch im JSR-316). Die Grundlage für die Extensibility ist die Erkenntnis, das man nicht alles in die Plattform stecken muss, sondern dass die Plattform wirklich, ja was, eine Plattform für andere Frameworks sein sollte. Immerhin, die Erkenntnis ist für die Java EE Plattform wirklich neu. Klingt aber gut, denn mir geht das, beispielsweise mit den Appservern als Ergebnis von Java EE, oft so, dass ich viele der angebotenen Dienste nicht brauche. Andere auch nicht, und das ist wohl der Grund, warum der Tomcat als "App-Server light" so beliebt ist. Sorry, ich bin abgeschweift.

Johnson ist mittlerweile schon bei den Profiles. Es wird erst mal drei davon geben und sie sind Ausprägungen der Plattform. Die einfachste Variante "Profile A" (ich denke mal, dass sich der Name noch ändern wird) ist im wesentlichen der Tomcat: Servlets, JSPs, EL und JSTL und solche Sachen. Wichtig sind dabei Änderungen in der Sichtweise: Die Extensibility schlägt wieder zu und so muss man z.B. nicht immer alles von Hand in die web.xml eintragen. Stattdessen wird es eine API dafür geben, so dass Frameworks einfacher auf der Java EE (light) Plattform aufsetzen können.

Profile B ist Profile A plus persistence und zwei Komponenten-Modelle (mit Fragezeichen). Eventuell wird es ein EJB 3.1 light geben, was auch immer das sein wird. Das zweite wird evtl. ein Web Beans Modell sein (JSR-299). Profile C wird ziemlich genau das sein, was wir jetzt schon als Java EE haben. Rod Johnson hat jetzt schon auf den Folien stehen, dass das volle Java EE wenig Relevanz hat.

Für Sun ist das natürlich eine gute Strategie: Mit dieser Strategie kann sich Java vielleicht noch ein paar Jahre unten gegen Ruby und oben gegen Dot.Net verteidigen. Ob es für Entwickler wirklich einen echten Effekt zeigt, wird sich noch zeigen: WebLogic, WebSphere und JBoss werden natürlich ihre Produktstrategie ein Stück weit unabhängig von Sun überdenken. Die Tendenzen dort gehen ja eher dahin, immer mehr in die Produkte zu packen - und sei es nur als Marketing Fake. Aber das ist ein anderes Thema. Rod Johnson kommt zu ähnlichen Schlüssen auf seiner nächsten Folie. Interessant, die nächste Statistik kommt auch (siehe oben) - Tomcat ist die am häufigsten eingesetzte Plattform für Enterprise Java. Was Sun hier also als Strategie fährt ist einfach ihre Anpassung an die Realität. An die Realität, die wir hier im Auditorium schon alle leben.

Jetzt zu den lange angekündigten Predictions:
"Real competition will return to the application server market", jaja, Tomcat kann sich dann auch den Java EE-Stempel aufkleben und damit hat man einen weiteren Marktteilnehmer. Und neben Tomcat noch viele andere. Damit gibt es eben eine niedriger Markteintrittsschwelle. Ok, im wesentlichen hatte ich den Punkt ja oben auch schon, denn der Punkt ist doch, dass die vollen Java EE Appserver Funktionalität realisieren, die nur die wenigsten nutzen. Geht mir im übrigen auch so - im letzten Projekt hatten wir einen WebLogic, benutzt davon haben wir die Servlet Engine für die WebServices und JMS. Das hätten wir auch mit dem Tomcat machen können.

Prediction 2: "Tomorrow's application server will be lightweight and modular". Die JBoss-Leute schreien jetzt "haben wir schon, haben wir schon". Richtig. Und alle anderen werden laut Johnson auf OSGi als technische Basis setzen.

Prediction 3: "Tommorow's application server will not merely implement JCP specifications". Komisch - das tun sie doch heute schon nicht. Und wenn, dann pushen sie ihre originären Sachen als neue Standard-Vorschläge. Aber Johnson führt das noch ein bisschen aus: Es wird nicht nur JCP standards geben, sondern z.B. auch die von der OSGi Allience. Viel interessanter ist der Umkehrschluss, in dem Rod Johnson ausführt, dass der JCP nicht immer das Rad neu erfinden muss. Wer braucht commons logging, wenn es schon log4j gibt. Wer braucht ein neues EJB-Konzept, wenn es Spring gibt. JSR 277, wenn es OSGi gibt. Ob sich diese Einstellung endlich durchsetzen kann? Ich bin kein Fan davon, dass es nur (Gedanken-) Monopole gibt und wer eine bessere Idee hat, der sollte sie auch in Code umsetzen. Aber oft ist es eben keine bessere Idee, manchmal noch nicht mal eine andere. Eben nur eine andere Organisation - das not invented here Phänonomen macht auch vor dem JCP nicht halt. Damit kommt auch die extended prediction: the JCP will run on open source.

Prediction 4: The market will address the gap between Tomcat and WebLogic/WebSphere. Das stimmt, denn das stimmt ja auch jetzt schon. Nur dass sich zum Teil jeder seine eigene Lösung strickt. Man kann auch einen Tomcat so produktiv einsetzen wie den WebLogic.

Prediction 5: The gap between application servers and ESBs will be bridget. Naja, das ist noch ein langer Weg. Es ist zum Beispiel immer noch ein weiter Weg dahin, dass meine Plattform entscheidet, ob es jetzt aus Lastgründen einen lokal deployten Service nutzt oder den gleichen Service auf einer anderen Maschine. Aber solche Features wären für mich ein echter Fortschritt auch für den SOA-Gedanken. Und auf den SOA-Gedanken kommt Rod Johnson auch gerade, klar, der liegt bei dem Thema ja nahe und das Buzzword trägt immer noch.

Prediction 6: The Black knight will be defeated. Oder anders ausgedrückt: EJB ist dying. Jaja, das ist keine Prediction, das ist eine Beobachtung. Wer macht schon EJB, wenn er stattdessen Spring machen kann. Interessante Statistik wieder - in den USA sieht man das mit EJB offensichtlich (noch) etwas anders. Aber - die erste witzige Statistik - die Kurven für die Entwicklung von Java EE und Cobol gleichen sich wie ein Ei dem anderen. Beides Legacy-Techniken.

In der Conclusion gesteht Johnson ein, dass Java EE 6 die Relevanz von Java EE erhöht, aber dass Java nicht mehr die Zukunft bestimmen wird.

Auf zur nächsten Session.