Spring 2.0 Countdown....
Der Spring 2.0 Countdown läuft
hier. Dienstag ist es dann soweit. Wer die Neuigkeiten in 2.0 noch nicht kennt, findet die Liste
hier.
JAOO
Nächste Woche bin ich auf der
JAOO in Dänemark. Eine nette Konferenz mit einer Menge sehr interessanter Vorträge. Wir sind folgendermaßen vertreten:
- Rod Johnson spricht darüber, wie er den Stand von Java EE wahrnimmt
- Ich gebe ein Tutorial über Spring und Persistenz,
- hoste den Performance-Track
- und gebe eine Präsentation über Spring und Patterns
Ich bin gespannt, was sonst noch an interessanten Vorträgen kommt - stay tuned!
Die 90er sind vorbei
Wie
hier lesen kann, hat
SGI" IRIX auf MIPS abgekündigt. Damit enden endgültig die 90er: Damals waren die Maschinen ein Traum und haben uns Dinge wie Jurassic Park oder Terminator 2 beschert. Video on Demand gab es prototypisch auf großen Challenge Servern, mittlerweile funktioniert es tatsächlich da draußen im Internet. Einige Zeit sah es so aus, als würde SGI die Welt übernehmen: Man kauft Cray, MIPS und Alias, es gab die MIPS-basierte Plattform ACE für Windows NT. Tja, und nun baut man auf Linux und Itanium - so ändert sich die Welt.
Moral: Auch wenn man einen technologischen Vorteil hat, muss man daran arbeiten, dass man ihn erhält. Sonst werden irgendwann
Supercomputer zu Kühlschränken.
Donnerstag Lehmanns Hamburg
Und am Donnerstag gebe ich dann einen Vortrag über Spring und AspectJ bei Lehmanns:
Donnerstag, 28. September 2006, um 20 Uhr
Lehmanns Fachbuchhandlung / Kurze Muehren 6 / Naehe Hauptbahnhof
Eine
Anmeldung ist nicht notwendig, aber hilfreich fuer die Planung.
Infos finden sich unter
http://www.lob.de/hamburg.
Java Starter Days Montag
Am Montag bin ich in Frankfurt bei den
Java Starter Days. Details meiner Session finden sich
hier.
Strategy Pattern Revisited
Das Strategy-Pattern aus dem ursprünglichen GoF-Buch ist eigentlich nahezu trivial: Kapsel einen Alogorithmus in einer eigenen Klasse. Wenn man "Klasse" durch "Modul" ersetzt, ist man wieder bei der alten Modularisierung. Das an Strategy ist, dass man Modul bzw. Klasse leicht austauschen kann und so die Implementierungen leichter ändern kann.
Meiner Ansicht nach ist daher eine Dependency Lösung wie Spring der nächste Schritt: Dabei kann man das konkret zu nutzende Modul extern konnfigurieren. Mein Eindruck ist, dass dadurch Strategy nochmal aufgewertet wird und in Spring-Systemen auch recht häufig zu sehen ist.
Java "Bloat"
Eine weitere interessante Geschicht für Java ist, dass Java SE 6 einige Features nicht mehr haben soll, wie
hier nachzulesen. Allerdings geht es dabei um ganze Pakete,
deprecated Methoden wird es wohl noch bis an's Ende der Tage im JDK geben. Ich bin nicht sicher, ob das eine gute Idee ist. Vorteil ist aus meiner Sicht vor allem, dass es einfacher wird ein JDK zu implementieren. Die paar MB, die das JDK durch solche Features größer wird, kann ich mir nicht wirklich als Problem vorstellen. Und bisher gibt es als Kandidaten auch nur das Midi-Kit (das nun tatsächlich nicht so wichtig ist). Interessant ist, dass man auch CORBA rausnehmen wollte, was nun wirklich nicht die beste Idee ist, weil immer noch viele darauf aufbauen.
Das wirkliche Problem ist allerdings, das die Bibliotheken umfangreicher werden und damit auch schwerer verständlich. Nur gerade dieses Problem löst man so nicht, da eben die Größe der Bibliotheken im wesentlichen gleich bleibt und Midi wahrscheinlich nicht die beste Sache ist. Deprecated-Methoden herauszuwerfen ist meiner Ansicht nach auch keine Lösung (und wird eben auch nicht passieren), weil das unnötig bestehenden Code bricht.
Aus meiner Sicht gibt es die Chance, eine Abstraktion über Java zu bauen. Spring geht hier schon recht weit, weil es Bibliotheken als Abstraktionsschichten enthält. Ein anderer interessanter Gedanke ist, auch andere Sprachen, die auf der JVM laufen, als eine solche Abstraktion zu sehen: Sie bieten auch einen anderen Zugriff auf die Java-Features und -Bibliotheken. Vor allem sind diese Ansätze sinnvoll, weil Java eben durch die vielen Bibliotheken auch viele Möglichkeiten bietet - eine EInschränkung der Bibliotheken erscheint da kaum sinnvoll.
Closures für Java
Eine der Neuerungen, die sich in Java SE 7 ankündigen, sind
Closures (siehe auch
hier. Dabei geht es im wesentlichen darum, eine Erweiterung zu schaffen, mit der man Funktionen als Variablenwerte verwenden kann. Man kann also einer Variablen eine Funktion zuweisen oder ad hoc eine erstellen. Dies hat weitreichende Konsequenzen. In Java SE betrifft dies zum Beispiel die Collections: Man muss nicht mehr "per Hand" über eine Collection iterieren, sondern kann einfach die Funktion übergeben, die für jedes Element ausgeführt werden soll.
Bei Spring könnte man den Template-Ansatz vereinfachen. Bisher sieht die Verwendung des JmsTemplates zum Beispiel so aus:
jmsTemplate.send(new MessageCreator() {
public Message createMessage(Session session)
throws JMSException {
return session.
createTextMessage("Text Message");
}
});
(Es gibt in diesem Fall natürlich noch die Vereinfachung
jmsTemplate.convertAndSend("A Text Message"); . Aber davon wollen wir mal absehen. Mit Closures könnte man das ganze nun so schreiben:
jmsTemplate.send( (Session session) {
session.createTextMessage("Text Message");
}
);
In diesem Fall nutzt man nicht die Möglichkeit, eine Funktion einer Variablen zuzuweisen, sondern sie direkt einer Methode zu übergeben. Dies weißt auch auf das Problem bei der Sache hin: Im Prinzip ist das ganze eine Möglichkeit, etwas ähnliches zu tun, wie man es mit Inner Classes und Anonymous Inner Classes macht. Damit befindet man sich in der Zwickmühle: Inner Classes sind aufwändiger und vielleicht auch schwerer zu verstehen als Closures. So gibt es Entwickler, die das Schreiben eines
ActionListeners für einen
JButton berechtigterweise als kompliziert empfinden. Aber man wird dieses Verfahren aus der Java Sprache nicht eliminieren können, weil man sonst vorhandene Software bricht und zwar viele vorhandene Software.
Somit schafft man einen zweiten Weg für dasselbe, was ich für ungeschickt halte, aber wohl nicht zu ändern ist und dem Fortschritt nicht im Wege stehen sollte...
Sun "kauf" JRuby
Wie man
hier lesen kann, stellt Sun gerade zwei Committer von JRuby ein. Eine
FAQ dazu gibt es auch. Meiner Ansicht nach ein sehr guter Schritt: Ich bin ja schon länger der Meinung, dass sich Java vor allem auf seine Stärke, nämlich die JVM und die gute Infrastruktur wie Application Server besinnen sollte. Durch diesen Schritt wird jetzt eine der wichtigsten dynamischen Sprachen direkt bei Sun auf der JVM implementiert. Das wird sicher viele weitere interessante Chancen schaffen. Interface21 selber hat in Spring 2.0 ja auch Support für dynamische Sprachen, so dass wir auch in diesem Bereich schon aktiv sind.
Java wird Open Source....
Wie bekannt, soll Java Open Source werden. Als Java Champion nehme ich natürlich an der Diskussion zu diesem Thema teil. Daher hier meine Meinung:
Die erste Frage ist natürlich, was sich durch Open Source überhaupt ändert, immerhin stehen die Sourcen ja zu einem großen Teil schon
hier oder
hier zum Download bereit. Dennoch ändert sich der juristische Status, was bedeutet, dass Java jetzt auch in Bereiche vorstoßen kann, die nie zuvor ein JDK betreten hat, also zum Beispiel einige Linux Distributionen oder auch Organisationen, die nur Open Source nutzen wollen. Gerade dies wird in Zukunft wichtiger werden, da zum Beispiel einige Länder signalisiert haben, dass sie in Zukunft nur Open Source nutzen wollen, um möglichst wenig von Technologie-Anbietern abzuhängen.
Ein mögliches Problem ist das Entstehen von Forks. Wenn man sich allerdings Open Source im Allgemeinen anschaut, so ist das generell kein so großes Problem. Das gilt z.B. für Linux, anders sieht es vielleicht bei BSD aus. Man muss eben einen Fork dauerhaft weiter pflegen, und diesen Aufwand dauerhaft zu betreiben, ist nicht so einfach. Außerdem ist man von den Bug-Fixes des eigentlichen Systems abgeschnitten. Und so ist trotz der sehr liberalen Apache Lizenz zum Beispiel bei Spring soetwas bisher nicht passiert und auch sehr unwahrscheinlich. Bei Java gibt es allerdings schon heute in gewisser Weise Forks, da es viele unterschiedliche JDK-Hersteller gibt, darunter Firmen wie BEA und IBM. Eine Rolle spielt sicher auch, dass Microsoft versucht hatte, eine inkompatible Version von Java auf den Markt zu bringen. Dieses Problem ist meiner Ansicht nach aber keines mehr, denn Microsoft hat mit .NET und J# mittlerweile eine andere Strategie zum Umgang mit Java.
Andere Lizenzen können Forks effizient verhindern - ein Beispiel ist sicher JBoss mit GPL und das Vorgehen gegen Apache Geronimo wegen dem Kopieren von Code (siehe dieser
Brief). Denn durch die GPL muss man seine Änderungen veröffentlichen, so dass man nicht "im stillen Kämmerlein" eine eigene Version erstellen kann, deren Änderungen nie veröffentlicht werden, und man kann den Code auch nicht unter einen anderen Lizenz wieder veröffentlichen.
Ein anderer Vorteil von Open Source ist die Innovation. Jeder kann sich beteiligen: Wenn ich eine gute Idee für eine Linux-Erweiterung habe, kann ich sie vorschlagen oder sogar implementieren und einbauen. Allerdings gibt es hier bei Java ein Problem, denn Java wird im Rahmen des JCP-Prozess standardisiert. Wenn ich einen tollen neuen Garbage Collection Algorithmus habe, kann ich ihn einbauen, weil es nach außen keine Änderung ist. Wenn ich aber eine geniale Idee für eine Modifiaktion am JDK habe, die eine Ergänzung zum Standard darstellt oder ihn gar bricht, muss ich durch den JCP-Prozess. Und der kann langsam sein. Man kann es an Spring und EJB 3 festmachen. Spring ist ein nicht standardisiertes Open Source Projekt, EJB 3 ein Standard, die beide im Java Enterprise Bereich zu Hause sind. Am 30.6.2004, als die ersten öffentlichen Versionen von EJB 3 / JSR 220 erschien, war Spring in Version 1.0.2. Als JSR 220 am 11.5.2006 final war, gab es Version 2.0M4 von Spring und dazwischen waren 1.1 und 1.2 erschienen. Dafür gibt es zahlreiche, gute Gründe wie die Integration anderer Persistenz-Ideen in JSR 220, und es gibt sicher schneller JCPs. Aber es zeigt auf jeden Fall, dass man ohne Standard schlicht schnell neue Versionen bauen kann und dadurch auch schnell Feedback aus der Praxis bekommt, mit dem man dann das Produkt iterativ verbessern kann. Und agile Methoden lehren uns, dass schnelles Feedback sehr wichtig ist.
Also: Auch wenn Java Open Source wird, werden Innovationen wie die Unterstützung von dynamischen Sprachen auch weiterhin in einem
JCP standardisiert und damit wird es - selbst wenn jetzt sofort jemand eine komplette und tolle Implementierung vorlegt - erst in Java SE 7 in 2008 kommen.
Fazit: Ich glaube, dass der Schritt letztendlich eine konsequente Fortsetzun der Strategie von Sun ist, Software-Assets in Open Source zu wandeln. Die Auswirkungen sind vor allem auf der politischen und juristischen Ebene zu suchen. Für uns als Techniker sollte sich nicht allzuviel ändern.
