Java Forum Stuttgart 2017

Das Java Forum Stuttgart fand 2017 zum nunmehr zwanzigsten Male statt, und ich war mal wieder vor Ort dabei, da das Vortragsprogramm aus meiner Sicht recht ansprechend war. Ich nutze das Java Forum hauptsächlich, um mal wieder dran erinnert zu werden, wie riesig das Java-Universum ist und wie viele Technologien und Frameworks es da gibt, Hype inklusive. Es gab zum Abschluss als Pecha-Kucha-Vortrag einen Rückblick auf die letzten 19 Veranstaltungen inklusive Blick auf die damals aktuellen Themen, da war einiges an damals hippem Zeugs dabei, das schon wenige Jahre später komplett in der Versenkung verschwunden war.

Aber das Thema soll ja weniger die Vergangenheit als die Gegenwart sein.

Los ging’s mit der JAX-RS 2.1-Schnellbleiche durch Markus Karg, der in der Expert Group des dazugehörigen JSR 370 mitarbeitet. Meine Expertise in diesem Bereich ist sehr begrenzt, aber ich konnte dem Vortrag inhaltlich sehr gut folgen und habe auf meine Todo-Liste “REST-API für CinePoll” geschrieben. Wie bei fast allen Technologien kann man ja viel drüber lesen, aber verstehen wird man es erst wenn man es nutzt. Interessant fand ich die Anmerkung, dass ja “im Prinzip” keiner mehr den großen Server am Start hat, sondern stattdessen alle Microservices im Docker-Container deployen. Dazu kann ich nur sagen: in manchen Branchen ist man noch lange nicht soweit.

Im nächsten Zeitslot habe ich ReactiveX mit RxJava besucht. Ursprünglich wollte ich da nicht hin, weil der vorgesehene Vortragende bei mir bei einer vorherigen Ausgabe des Java Forum einen eher durchwachsenen Eindruck hinterließ, und ich die Erfahrung gemacht habe, dass ein guter Referent wichtiger ist als ein spannendes Thema. Jan Blankenhorn hat hier seine Sache jedenfalls sehr gut gemacht, inklusive Live-Coding, was ja immer einen gewissen Risikofaktor beinhaltet. Jedenfalls nahm ich mindestens zwei Erkenntnisse mit: ich muss doch IntelliJ IDEA eine zweite Chance geben, und ich muss dringend Routine bei den neuen Java 8-Features bekommen – bei der Lambda-Notation muss ich immer zweimal hinschauen, um den Code zu verstehen. Da ich täglich im Beruf auf Java 7 limitiert bin, fehlt einfach der routinierte Blick darauf.

Dann war es wieder Zeit für Michael Wiedeking, diesmal mit dem Thema Über den Umgang mit Streams. Wie immer sowohl unterhaltsam als auch lehrreich. Und wieder ein Knoten im Taschentuch für “Java-8-Features”. Und sehr plastische Beispiele für die Komplexitätsbetrachtung von Operationen.

Auch den Slot vor dem Mittagessen bestritt ein alter Bekannter: Björn Müller von der CaptainCasa GmbH mit dem Thema Von Java-Swing, über JavaFX zu HTML für operativ genutzte Geschäftsanwendungen. Er berichtete von der Reise des CaptainCasa-Frameworks von der Swing-UI über die JavaFX-UI hin zur neuen HTML-UI. Der Ansatz von “RISC-HTML” führt zu höchst erstaunlichen Ergebnissen, die damit erreichte Performance der Oberfläche im Browser war aus meiner Sicht verblüffend. Die nicht immer ganz hasenreinen Ausführungen und Analogien zu CISC-vs-RISC bei den Prozessoren habe ich da gerne verziehen. Interessant auch die Einschätzungen und Erfahrungen zu JavaFX, die sich durchaus mit meinen Beobachtungen decken: am Markt gescheitert, Zukunft ungewiss. Die Krise der Cross-Platform-UI-Toolkits geht weiter.

Nach der Mittagspause ging es bei mir weiter mit Mobile hybride Applikationen – Investment-App der BW-Bank, präsentiert von Manfred Heiland von der avono AG. Cross-Platform-Lösungen interessieren mich seit Anbeginn der Java-Zeit mit dem Versprechen “Write Once, Run Anywhere”. Was auf der Serverseite nach wie vor prima funktioniert, ist im Bereich der grafischen Oberfläche ja schon längere Zeit eher schwierig. Swing war der letzte aus meiner Sicht einigermaßen erfolgreiche Versuch, ein Cross-Platform-UI-Toolkit an den Start zu bringen. Aber bezüglich mobiler Plattformen bringt das halt auch nix. Dort hat man im Prinzip die Wahl auf WebViews zu setzen, oder halt mehrfach native Apps zu bauen – ob Technologien wie Gluon hier irgendwann adäquate Lösungen erlauben, die auch über viele Jahre stabil bleiben, ist aus meiner Sicht noch unklar. Die Tatsache, dass iOS Objective C oder Swift nahelegt und Android Java erleichtert die Sache nicht. Und hier bietet das vorgestellte Projekt mit seinem Hybridansatz eine interessante Alternative. Die fachlogisch einfachen Teile, die die Steuerung der App übernehmen, werden nativ implementiert, diverse komplexere Inhalte hingegen, die hauptsächlich der Anzeige dienen, werden über WebViews gemacht. Offenbar gibt es inzwischen sowohl unter Android als auch unter iOS einigermaßen elegante Lösungen, per JavaScript in beide Richtungen zu kommunizieren, so dass mir der hybride Ansatz sehr plausibel erscheint. Laut Referent gab es auch keine Probleme, die Apps in die App-Stores zu bringen – das ist bei “ich kapsle meine Webanwendung einfach als App”-Variante ja nicht immer so problemlos.

Als passionierter Frontend-Entwickler habe ich dann natürlich UI Technologieradar besucht. Das erwies sich als nicht so besonders fruchtbar. Die versprochene “objektive Entscheidungshilfe bei der UI-Technologiefindung” erwies sich als eher simple Ansatz einer Bewertungsmatrix verschiedenster (aber immer noch sehr lückenhafter) UI-Technologien, wobei die Bewertungen sich als durch und durch subjektiv erwiesen. Die ausgearbeiteten Kriterien entsprachen ungefähr dem, was ein etwas erfahrener Consultant oder Entwickler nach 30 Minuten scharfem Nachdenken selbst erarbeitet hätte. Und es traten verschiedene Einschätzungen und Aussagen zu diversen Technologien hervor, die die Glaubwürdigkeit der ganzen Idee doch in einem ziemlich schalen Dämmerlicht erscheinen ließen – beispielsweise wurde die These aufgestellt, dass mit Java Swing ja nie jemand eigene Komponenten erstellt habe, während das bei diversen Webtechnologien gängige Praxis sei. Aus meiner Sicht eine komplett absurde Einschätzung und nur durch sehr enge Scheuklappen aus der eigenen Projekterfahrung zu erklären – was der Consultant noch nicht gesehen hat, gibt es nicht. Zu allem Überfluss bildeten die beiden Vortragenden auch noch einen scharfen Kontrast bezüglich ihrer präsentatorischen Fähigkeiten, was sich als sehr störend herausstellte. Präsentieren im Duo geht aus meiner Sicht nur, wenn beide sich entweder gut ergänzen oder gut aufeinander eingespielt sind. Keines von beidem war hier der Fall. Und als Schlusspunkt: das “UI Technologieradar” wurde in der Vortragsankündigung als fertig einsetzbares Tool charakterisiert – im Vortrag stellte sich allerdings heraus, dass es sich noch in einem sehr frühen Stadium der Entwicklung befindet. Ebenfalls in der Ankündigung: man würde Technologien wie React.js oder Spring MVC kurz kennenlernen. Das entpuppte sich als stark übertrieben: Spring MVC beispielsweise tauchte nur namentlich auf einigen Folien auf. Interessant auch ein innerer Widerspruch: auf mehreren Folien tauchte die These auf, dass GWT stark auf dem absteigenden Ast sei. Empfehlung: nicht mehr für neue Projekte verwenden. Kann man so sehen. Aber die Begründung, warum AngularJS so eine gute Wahl sei, war, dass eine große Firma wie Google dahinter steht. Finde den Fehler.

Den Abschluss bildete für mich die Pecha-Kucha-Session. Auch dieses Mal muss ich feststellen: das Format gibt mir überhaupt nix. Wenn der Vortragende gut ist (wie in diesem Falle mal wieder Michael Wiedeking), merkt man im Vortrag gar nicht, dass es im Pecha-Kucha-Style abläuft. Wenn der Vortragende schlecht ist (bzw. den Ablauf nicht häufig genug geübt hat, um das passende Timing zu entwickeln), passt die Folie nicht zum Gesprochenen. Und das Format scheint zur Nutzung nichtssagender Bilder zu animieren, denn dann passt die Folie auch automatisch zum gesprochenen Wort. Auf die einzelnen Vorträge (klassisches 20×20-Format, 5 Vorträge für die zur Verfügung stehenden 45 Minuten) will ich gar nicht detailliert eingehen und will nur den von Michael Wiedeking lobend hervorheben, der unter dem Titel “Schall und Rauch” sehr plastisch ausführte, wie kompliziert es ist sprechende Methodennamen zu finden. Aus meiner Sicht übrigens der Knackpunkt der CleanCode-Bewegung und ihrem Mantra “Kommentare überflüssig, der Code erklärt sich von selbst”. Das zeigte sich, als das Publikum abstimmen durfte, welcher Methodenname am passendsten zur beschriebenen Operation sei. Da herrschte kein klares Meinungsbild, was die Problematik doch sehr verdeutlicht. Essenz daraus: entscheide Dich für ein Wording, aber ziehe das dann auch konsistent durch – Du wirst es nie allen recht machen können.

Wer Beispiele für gelungene Pecha-Kucha-Vorträge kennt (also nicht nur: guter Vortrag, sondern Mehrwert durch die Tatsache, dass er dem Format folgt): gerne Links an mich schicken, vielleicht ändere ich meine Meinung.

Unterm Strich fand ich die Veranstaltung sehr gelungen. Die Vielfalt der Vorträge gefällt mir gut, preislich ein Schnäppchen, Top-Organisation, Verpflegung OK. Gut, die Liederhalle ist etwas in die Jahre gekommen, aber das stört nicht sonderlich. Also: nächstes Jahr wieder dabei. Hoffentlich wieder bei Vorträgen von Michael Wiedeking und Björn Müller.

Reflexe

Eine Meldung erschüttert die Grundfesten der deutschen Sprache: am Donnerstag gab der “Rat für deutsche Rechtschreibung” bekannt, dass das große scharfe S nun (endlich?) offizieller Bestandteil der deutschen Rechtschreibung werden soll. So berichten beispielsweise Die Welt oder SPIEGEL Online.

Mein erster Reflex (und deshalb landet dieser Artikel im IT-Blog, weil es eben der Reflex eines IT-geprägten Menschen ist): sind die wahnsinnig? Was ist denn der Unicode-Codepoint, und wie lange wird es dauern bis das Dingens in Tastaturtreibern und Fonts auftaucht? Ein kurzes Googeln später die Erkenntnis: das ist schon seit 2008 durch. Unicode-Codepoint U+1E9E, als HTML-Entity also &7838;. Unter Windows per Shift+AltGr+ß tippbar (nicht unter Windows 7, aber zumindest unter Windows 10). Und auch diverse Fonts sind bereits seit Längerem damit ausgerüstet: Arial, Times New Roman, Verdana und Tahoma seit Windows 7, unter den freien Schriften sind DejaVu und Bitstream Vera am Start. Also: das Rückenmark lag (dieses eine Mal) falsch.

Nichtsdestotrotz wäre mir die “Schweizer Lösung” lieber gewesen: ersatzlose Abschaffung des ß. Braucht kein Mensch. Zweitbeste Lösung: mit der bisherigen Situation leben. Kein Mensch braucht – abgesehen von Designern und Werbefuzzis – die reine Großschreibung (Versalsatz). Da geistern zwar merkwürdige Begründungen wie “Maschinenlesbarkeit” durch die Gazetten, aber das ist im 21. Jahrhundert kein valider Grund mehr. Auch nicht auf Personalausweisen.