JAOO: Dritter Tag
Heute habe ich nur wenige Sessions besucht. In der Keynote hat Cameron Purdy nocheinmal die Vorteile von Java gegenüber C++. Daraus wollte er dann die Probleme von Java ableiten, die eine neue Sprache lösen müsste. Dort kamen Themen wie Startup Time, Memory Footprint, Full GC Pausen usw - meiner Meinung nach nicht wirklich die großen Probleme.
Dann habe ich noch den Schluss von Beat Schweglers Vortrag über Microsofts Cloud-Pläne mitbekommen und mich geärgert, dass ich nicht früher bei dem Talk war.
Gregor Hohpe sprach über Googles Cloud Ansatz. Dabei ging es um das Google File System, Big Table für Datenhaltung und Map Reduce für die Verteilung von Arbeit. Wie auch Urs Hölzle vor ihm gab das einen guten und interessante Einblick darin, wie Google arbeitet.
Schließlich habe ich noch den Vortrag von Rod Johnson, dem Chef der SpringSource Division bei VMware angehört. Dieser Vortrag zeigt sehr deutlich, wo die Chancen von SpringSource un VMWare liegen. Die Folien gibt es
hier - reinschauen lohnt sich. Fast alle anderen Folien finden sich im
Schedule der Konferenz.
Labels: Beat Schwegler, Gregor Hohpe, JAOO, Rod Johnson
JAOO: Tag 2
Zunächst ein Nachtrag zum ersten Tag: Ich war auch in einem Talk von Jonas Jacobi zu WebSockets. Interessant war dabei neben WebSockets auch das Stomp-Protokoll, mit dem man in JavaScript von ActiveMQ Mesages empfangen kann - und das sehr problemlos.
Der zweite Tag ging los mit einer Keynot von Simon Peyton-Jones (Microsoft Research) zu Haskell, einer funktionalen Programmiersprache, und zwar insbesondere zu dem Typ-System und der Modellierung von Klassen in dem System. Inhaltlich fand ich es sehr interessant, aber sicher auch eher schwer zu verstehen. Gleichzeitig zeigt die Keynote, dass Sprachen wieder ein Thema sind. Lustig ist vor allem, dass vor längerer Zeit ein Bekannter Haskell an der Uni lernen musste und sehr negativ dazu eingestellt war - weil es ihm akademisch und nicht praxisrelevant erschien. Jetzt scheint Haskell in der Nutzung auch außerhalb der Unix zumindest zuzulegen und Microsoft Research wird sicher nicht "einfach so" Experten in dieser Sprache eingestellt haben.
Den Start des von mir organisierten "Java Now" Tracks gab es auch eine Art Keynote. Rod Johnson, Erfinder von Spring und Chef der SpringSource-Division bei VMWare, sprach über den Trend zu Open Source und leichtgewichtigen Ansätzen bei Java. Ich fand diesen Vortrag vor allem wichtig, um auf die große Bedeutung von Open Source als Innovator bei Java hinzuweisen.
In diesem Sinne ging es dann weiter: Dalibor Topic (Sun) sprach über das OpenJDK-Projekt, dessen Leiter er ist. Neben den Innovationen wie Type Annotations habe ich vor allem mitgenommen, dass Java noch mehr Verbreitung findet, seit es Open Source ist. So steht es jetzt in jeder Linux-Distribution zur Verfügung und auch in vielen anderen Betriebssystemen wie beispielsweise BSD. Später zeigte Dalibor mir noch eine Grafik, die zeigt, dass es auch immer mehr Open-Source-Projekte gibt, die auf Java setzen. Also wird durch das OpenJDK-Projekt Java noch populärer.
Martin Lippert sprach dann über OSGi auf dem Server, meiner Meinung nach eines der wichtigsten Zukunftsthemen für Server-Java. Schön war, dass Martin auch der Meinung ist, dass der SpringSource dm Server in diesem Bereich im Moment die beste Lösung darstellt. Inhaltlich ging Martin neben den Grundlagen - also den Problemen, die man bei OSGi auf dem Server hat - auch auf die neuen Architektur-Herausforderungen wegen der Dynamik von OSGi ein. Ich denke, dass in diesem Feld noch einige interessante Ansätze möglich sein werden.
Kirk Pepperdine sprach über Latenzzeiten. Gerade bei automatisierten Börsen-Systemen können Latenzen sehr wichtig sein. In seinem Talk hat er dann einen vollständigen Ansatz zur Analyse von Performance-Problemen dargestellt - was für eine Stunde eine große Leistung ist.
Am Abend gab es dann noch eine Diskussion mit James O Coplien und mir bei der JavaGruppen zur Zukunft von Java. An dieser Stelle nochmal mein Dank an JavaGruppen und Martin Boel für die Organisation. Insgesamt gab es eine lebhafte Diskussion und ich hoffe, dass dabei klar geworden ist, dass Java und die JVM eine sehr positive Zukunft haben werden.
Labels: Dalibor Topic, James O Coplien, JAOO, Kirk Pepperdine, Martin Lippert, Rod Johnson
JAOO Java Track
Ich habe dieses Jahr die Ehre, den Java Track auf der JAOO in Århus, Dänemark, zu organisieren. Das ist vor allem eine Ehre, weil die JAOO ursprünglich eine reine Java-Konferenz war und somit dieser Track sozusagen eine Art Kern der Konferenz darstellt.
Das Programm ist nun unter
http://jaoo.dk/aarhus-2009/tracks/show_track.jsp?trackOID=264 online.
Erster Sprecher wird Rod Johnson sein, CEO von SpringSource. Dabei geht es um Innovation durch Standards und Open Source. Traditionell sind Standard bei Java ja wichtig gewesen, aber das ändert sich gerade. Und Open Source Projekte - wie Spring, Tomcat, Eclipse usw - werden langsam zu den wichtigsten Technologien im Java-Bereich. Die Details können sich aber durchaus noch ändern.
Wegen Open-Source-Thema freut es mich, Dalibor Topic als nächsten Speaker gewonnen zu haben. Er ist der Leiter des Open-JDK-Projekts und arbeitet dadurch an einer sehr zentralen Stelle im Open-Source-Java-Bereich. Gerade durch den Kauf von Sun durch Oracle ist es wichtig, sich noch einmal zu vergegenwärtigen, dass Java eben Open Source ist und kein Sun-Projekt. Außerdem sind für viele Java-Entwickler die konkreten Konsequenzen des Open-JDK-Projekts für ihre tägliche Arbeit noch nicht erkennbar. Das soll dieser Talk korrigieren.
Eine wichtige technische Innovation im Java-Bereich ist OSGi, vor allem auf dem Server. Zu diesem Thema konnte ich Martin Lippert gewinnen, der ja eine der herausragenden Größe in diesem Bereich ist. Themen wie Modularisierung und Dynamisierung werden Java-Server-Anwendungen sicher deutlich ändern und ich bin auf Martins Ausführungen diesbezüglich gespannt.
Schließlich gibt Gary Sevitsky einen Talk über speichereffiziente Java-Anwendung - ein konret uns praktisch wichtiges Thema. Den Abschluss bilde ich dann selber mit einem Überblick typischer Probleme in Java-Anwendung - ein Resultat der vielen Code-Reviews, die ich durchgeführt habe.
Und mein Kollege Arjen Poutsma organisiert dann noch den Spring-Track, siehe
http://jaoo.dk/aarhus-2009/tracks/show_track.jsp?trackOID=274 .
Labels: Arjen Poutsma, Dalibor Topic, Gary Sevitsky, JAOO, Java Magazin, Martin Lippert, Rod Johnson
JAOO: Help! Which web Framework should I use? (Alef Arendsen, Interface21)
In dieser Session gab mein Kollege Alef Arendsen eine Übersicht über Web Frameworks. Da Alef wie ich auch für Interface21 arbeitet, ist er natürlich voreingenommen.
Er zeigte erstmal Servlet-Code, wie er 1997 war. Dann JSPs als nächster Schritt, dann die Trennung zwischen View und Controller. Und dann kam Struts, das diesen Ansatz ebenfalls implementiert. Und das war dei Evolution nur bis 2001. Und bis heute (2007) ist noch eine ganze mehr Menge an Frameworks gekommen. Also: Welches soll man benutzen? Die typische Berater-Antwort: Das kommt darauf an...
Es gibt viele nicht-technische Aspekte, die man beachten muss:
- Gibt es eine ausreichend Große Community?
- Gibt es (kommerziellen) Support?
- Wie ist in der Vergangenheit mit Rückwärtkompatibilität umgegangen worden?
- Nutzt es wirklich schon irgendjemand?
- Hat das Team viel Erfahrungen mit einer bestimmten Technologie? Macht es dann Sinn, eine neue einzuführen?
Technisch gibt es unterschiedliche Aspekte, und die Frameworks eignen sich für unterschiedliche Themen. Dabei geht es vor allem darum, die rechte Abstraktionsebene zu finden. Es gibt eben keine Evolution von Struts zu JSF, es sind zwei unterschiedliche Ansätze.
Nehmen wir als Beispiel eine Anwendung mit einem zustandsbehafteten Workflow. Das Beispiel ist ebookers.com, bei dem man Reisen buchen kann. Soetwas kann man als einen Ablauf bzw. Workflow modellieren. Dazu kann man Spring Web Flow nutzen. Man kann dann den Ablauf in Eclipse grafisch modellieren. Dabei ist das Zustands-Management vollständig transparent und wird einfach vom Zustands-Automat ausgeführt. Man kann auch Teile des Ablaufs wiederverwenden und man zum Beispiel den Back-Button besser unterstützten. Allerdings muss man dazu den Zustand in der Http-Session, in der Datenbank oder auf dem Client speichern. Dabei werden Ressourcen verwendet, was die Skalierbarkeit beeinflusst.
Als Beispiel für eine zustandslose Anwendung zeigte er ilse.nl, die zweitgrößte niederländische Suchmaschine. Sie ist vollständig mit Spring MVC implementiert. Der Betreiber dachte zuerst, er könnte die Anwendung nur mit C++ implementieren. Ein Trick hier war, die Views mit SAX zu rendern und die Anwendung vollständig zustandslos zu implementieren. Für die Anwendung werden 3 Maschinen für das Frontend genutzt und 2 für das Backend. Eine ähnliche niederländische Seite benötigt anscheinend 400 Maschinen. Die letzteren haben allerdings einen zustandsbasierten Ansatz.
Was ist mit zustandsbehafteten Modellen? JSF hat ein limitiertes Navigations-Modell, weil es keine Navigations-Regeln gibt. Also muss man ein Framework wie Spring Web Flow nutzen, um das zu JSF hinzuzufügen. Diese Regeln kann man in XML (oder auch in Java) definieren. Alef zeigte dann ein Beispiel für einen Flow, der sogar Ausdrücke für die Steuerung des Ablaufs enthielt.
Google Web Toolkit hat einen ganz anderen Ansatz. Es kompiliert Event-Handling-Code, der in Java geschrieben ist, zu JavaScript, der dann im Web-Browser ausgeführt werden kann. Eine Integration zum Beispiel in Spring Web Flow gibt es noch nicht, aber darüber wird zumindest nachgedacht. Das Programmiermodell von GWT ähnelt einem traditionellen GUI-Modell wie AWT oder Swing.
Bei Struts, Spring MVC und Struts 2 hat man ein Request/Response-orientiertes Modell, das man allerdings durch Spring Web Flow ergänzen kann - wenn es notwendig ist.
Ein weiterer interessanter Gedanke: Sollte die HttpSession vielleicht durch Zustand entweder auf dem Client oder dem Server abgelöst werden? Immerhin ist die Http-Session eigentlich nur ein Hack, um ein zustandsloses Protokoll mit Zustand zu versehen.
Aber weiter mit dem Vergleich: JSF speichert die Zustand der Komponenten in der Session, was eben die Skalierbarkeit negativ beeinflusst. Dependency Injection und Navigation kann zum Bespiel durch Spring und Spring Web Flow ergänzt werden. Spring Web Flow speichert den Zustand auf dem Server - entweder in der Session oder in der Datenbank. GWT hingegen nutzt den Client für den Zustand. Der Zugriff auf den Server ist explizit, so dass man merkt, was man tut. Das ist gut, weil Remote Zugriffe eben wesentlich langsamer sind als lokale Aufrufe. Allerdings hat es keine Lösung für Dependency Injection - und es gibt noch keine Integration mit Spring. Natürlich kann man Spring immer noch auf dem Server nutzen. Struts, Spring MVC und Struts 2 haben keine eigene Features für Zustand - außer der Session. Dependency Injection kann man zum Beispiel durch Spring "nachrüsten". Diese Frameworks eignen sich also vor allem für zustandslose Anwendungen.
Was ist also mit Templating oder GUI-Design? Bei GWT kann man das HTML nicht mehr wirklich ändern oder gar von einem Designer ändern lassen - man kann allerdings CSS zum Anpassen des Design nutzen. Mit JSPs kann man Tag Libraries nutzen. AJAX muss man dann aber selber irgendwie mit JavaScript bauen. Da HTML-ähnlich ist, kann man es eher vpn Designer bearbeiten lassen. FreeMarker oder Velocity ist im Prinzip ähnlich. JSF ist deutlich anders. Es bietet auch Chancen für Anbieter von Komponenten. Man sollte es auf jeden Fall mit Facelets nutzen. AJAX ist durch einige Erweiterungen wie z.B. Spring Faces, IceFaces etc. integrierbar.
Ingesamt ein ganz gute Überblick - und die Session war auch sehr gut besucht.
Labels: Alef Arendsen, JAOO, JAOO2007, Spring MVC, Spring Web Flow, Web Frameworks
