5 Tage Power Workshops und
Konferenz sind geschafft. Ich bin geschafft. Aber glücklich und voller
Inspiration und neuer Erfahrungen.
Für heute hatte ich einen Power Workshop
zum Thema Entwicklung von Eclipse RCP-Programmen (Rich Client Platform)
ausgewählt. Sehr interessant, wie das ganze mit den Plugins und Features
und den Extension Points funktioniert. Ich bin jetzt schon ganz gespannt
auf den Lotus Expeditor und den Notes 8 Standard Client. Und ganz heiß
darauf, mein neues Wissen mal auszuprobieren. Jetzt brauche ich nur noch
eine sinnvolle Idee für ein kleines Experiment. Ich glaube, ich weiß schon
was 
Ansonsten war die JAX eigentlich wie
immer: noch größer als im Vorjahr, irgendwie noch mehr Veranstaltungen
(morgens ging es um 8:30 Uhr los, abends gab es auch eine Keynotes bis
21:30 Uhr... mit über eintausend Zuhörern! Die sind verrückt. Ich darf
das schreiben, ich war selbst dabei.) Apropos Abend-Keynote: Die hat Brian
Goetz von Sun gehalten - Titel: "Java Performance Myths". Inhalt:
ausgezeichnet, Stil: super. Kurzform: Java war mal langsam, ist jetzt aber
sauschnell.
Zum Teil schneller als C! Unglaublich?
Das liegt daran, dass der "gewöhnliche" C-Programmierer nicht
jedes Programm bis ins allerletzte optimiert (und es weltweit auch nicht
so viele Leute gibt, die das richtig können). Außerdem darf man mit C zum
Beispiel bei der Speicherverwaltung alles machen. Ergo, kann der Compiler
eigentlich nichts optimieren. Der Java-Programmierer ist hingegen relativ
eingeschränkt. Dadurch können die Sun-Entwickler aber viele richtig fiese
Optimierungen in die JVM einbauen, so dass die Ausführung im Dauerbetrieb
(nachdem eine Methode irgendwann compiliert wurde) performanter sein kann.
Dazu kann die JVM bei den Optimierungen mit Annahmen arbeiten: die sind
häufig richtig und beschleunigen den Code. Erweist sich später die Annahme
als falsch, wird mit den bis dahin gesammelten Ausführungsdaten die Methode
eben noch einmal anders übersetzt - wieder optimiert. Der statische C-Compiler
kann das nicht, weil er eben keine Chance hat, diese Daten bei der Ausführung
zu sammeln.
Weitere Erkenntnis: Micro-Benchmarks
funktionieren nicht. Es gibt so viele Nebenbedingungen und -effekte, dass
diese kleinen, künstlichen Benchmarks, die in einer Schleife immer wieder
das gleiche machen, zu unzuverlässig sind, um daraufhin Entscheidungen
zur treffen. Er hat zum Beispiel gezeigt, dass es schneller ist, erst 2
zu addieren und dann 1 abzuziehen, als immer nur 1 zu addieren. Natürlich
ist das Quatsch. Aber eben Quatsch, der als Ergebnis aus einem Micro-Benchmark
rausgekommen ist.
Und: Sauberen, "dummen" Standard-Code
schreiben. Viele Versuche, mit Tricks und von Hand den Code zu optimieren,
gehen nach hinten los. Sicher ist, dass der Code schlechter wartbar ist.
Und meistens ist er nicht schneller. Das liegt daran, dass die JVM heutzutage
einen verdammt guten Job bei der Optimierung zur Laufzeit macht. Viele
Synchronisierungsblöcke, indirekte Aufrufe usw. werden einfach wegoptimiert,
wenn dies in der konkreten Situation zur Laufzeit möglich ist.
Mein Respekt an die JVM-Optimierer von
Sun!
Und bei der JAX wird mir auch immer
wieder klar, wie toll es wäre, wenn wir eine aktuelle JVM im Notes-Client
und mehr noch im Domino-Server zur Verfügung hätten. Aktuell ist Version
6 der Java SE. Irgendwann im Sommer kommt Notes/Domino 8 mit der 5er JVM
(einer von IBM modifzierten!). Bis unsere Kunden auf Notes 8 wechseln,
ist wahrscheinlich schon Java 7 oder 8 aktuell 
Sei's drum: Alles wird besser .
