Radikalschnitt

Die letzten Wochen standen bei mir ganz im Zeichen sehr vieler Schulungstage. Zuerst im Rahmen mehrerer Fachinformatikerausbildungen zu Python und MySQL, aber die letzten 3 Wochen komplett zu Java und JavaFX/OpenJFX. Dabei ging es bei purem Java um eine „Werkstatt“ im Rahmen der Fachinformatikerausbildung, bei der noch mit Swing gearbeitet wurde.

Bei dem Kurs zu JavaFX habe ich hingegen professionelle Java-Entwickler einer Berliner Behörde geschult, die vorher bei einem anderen Trainer einen Kurs zu Maven gemacht hatten und danach eben noch JavaFX kennenlernen sollten. Zum Teil hatten die aber auch schon vorher mit JavaFX gearbeitet.

Der JavaFX-Kurs war bereits früher angesetzt gewesen, aber der
eingeplante Trainer war ausgefallen und ich habe den Kurs mit einem neuen Termin kurzfristig übernommen. Die beiden Tage habe ich zwar recht schwer untergebracht und eigentlich war ich bereits so ausgelastet, dass ich im Grunde keine Termine mehr annehmen wollte. „Radikalschnitt“ weiterlesen

Neu erschienen – mein JavaFX Grundkurs bei LiL

Über den Sommer habe ich mehrere Training bzw. Aktualisierungen für LinkedIn Learning eingespielt, deren endgültige Fertigstellung bzw. Produktion sich dann doch ziemlich hingezogen haben. Nicht zuletzt Corona hat Arbeitsabläufe und Kapazitäten sowie Prioritäten im Griff,. Aber die Woche ging es wie beim Bretzelbacken und neben der Aktualisierung meines Training zu den Neuerungen der verschiedenen Versionen von Java und meinem aktuellen Entwickler-Tipp zu Python ist diese Woche auch der JavaFX Kurs erschienen. Dabei geht es neben JavaFX auch um FXML und den Sceen Builder sowie NetBeans, Maven, Ant, Gradle, JDK etc..

Ich habe schon früher Kurse zu JavaFX eingespielt (sogar schon zu Zeiten von Video2Brain (V2B), aber auch dann Aktualisierungen für LiL), aber die sind mittlerweile komplett veraltet. Der neue JavaFX Kurs ist deshalb vollkommen neu konzipiert und vollständig neu eingespielt. Außer ein paar Ideen für Beispiele ist nichts mehr identisch zu den alten Kursen.

Was übrigens auch JavaFX als Technologie betrifft. Diese hat sich zum Teil komplett inkompatibel zu älteren Versionen weiterentwickelt. Offiziell heisst sie jetzt sogar nicht mehr JavaFX, sondern OpenJFX und wird nicht mehr von Orcale verantwortet, sondern einer OpenSource-Organisation. Wobei sich der Bezeichner „OpenJFX“ wohl nicht so richtig etablieren will und man deshalb an den meisten Stellen doch wieder den ursprünglichen Bezeichner „JavaFX“ beibehält.

JSF/MyFaces, Microservices, Maven & Co

Ich habe die ersten drei Tage der Woche eine Einzelschulung zu erweiterten Java-Themen gehalten. Es ist kaum zu glauben, aber das war die erste Live-Schulung seit 1,5 Jahren. Obwohl ich in der Zeit sogar sehr viele Schulungen gehalten habe, waren sie allesamt online.
Bei der Schulung ging es grob gesagt um Java. Aber keine Einsteiger-Themen, sondern um eine Betrachtung diverser Themen im Java-Umfeld samt Web für einen erfahrenen Programmierer, der sich mit den Techniken bereits auskennt. So Sachen wie

  • JUnit, Git und Github,
  • Maven und andere Build-Tools wie Gradle und Ant,
  • Docker,
  • Übersicht neue Java-Techniken (vor allen Dingen Lambda-Ausdrücke, Closures und das Modulsystem)
  • JavaFX/OpenJFX/FXML
  • Ausblick Mobile, Android Studio, Cordova
  • Tomcat bzw. Java-Container als Server (Wildfly)
  • JSP/Servlets/JSF
  • Refactoring
  • Microservices (Spring)

Bei der Anfrage hat mich allerdings das Thema JSF (Java Server Faces) doch schwer verwundert. Ich hatte in der Vergangenheit JSF durchaus mehrfach geschult, aber seit Jahren eigentlich nichts mehr damit zu tun. Und ich bin davon ausgegangen, dass das Thema JSF eigentlich ziemlich out ist. So hatte ich das auch schon vor einigen Jahren beurteilt und mich deshalb aus dem Themenkomplex weitgehend zurückgezogen. Die vereinzelten Anfragen zu JSF-Kursen habe ich auch immer abgelehnt. Überhaupt sah und sehe ich bei den Java-Frameworks für das Web eigentlich nicht (mehr) das große Potential. Weder bei JSF (oder gar Servlets/JSP), noch Spring oder Struts.

Aber mein Teilnehmer wechselt demnächst beruflich als IT-Leiter in eine Behörde, die wohl mit JSF 2.3 arbeitet. Alttechnologien halten sich oft ewig. Ich habe ja auch einen Standardkunden, der noch mit Cobol arbeitet.

Da diese Schulung als eine Art Workshop mit Wissensaustausch gewünscht war und JSF etc. nur einen Teil der Agenda ausgemacht hat, habe ich die Sache angenommen. JSF und Web haben wir dann auch geschlossen am dritten Tag abgearbeitet.

Rückblickend war es auch verdammt spannend, sich wieder in die Welt von JSF einzuarbeiten. Wobei dabei uns beim Voranarbeiten ganz interessante Phänomene untergekommen sind, von denen mir immer noch nicht ganz klar ist, ob wir auf den Grund der Tatsachen getaucht sind oder uns verirrt haben.

Gerade bei Java im Web-Umfeld ist m.E. erst einmal die Konfiguration die größte Einstiegshürde. Vor allen Dingen, wenn man da nicht täglich am Schaffen ist. Das fängt schon mit der Konfiguration der Server an. Ganz banal bei der lästigen Tomcat-Einstellung in der Datei tomcat-users.xml, wo mit

<role rolename="manager-gui"/>

<user username="admin" password="admin" roles="standard,manager-script,manager-gui" />

erst einmal freigeschaltet werden muss, dass der Server über das Webinterface administriert werden kann und war-Dateien überhaupt deployed werden dürfen. Mit Wildfly ist es auch nicht einfacher bzw. bequemer.

Da Maven in der Schulung ein großes Thema war, haben wir viel mit Architypes gearbeitet. Auch bei JSF, was wir in der Version 2.3 als Basis genommen haben. Neben den Schablonen in Netbeans und Eclipse, die mit Maven, Ant oder Gradle arbeiten.

Neben dem elenden Konfigurieren über die web.xml und die faces-Konfigurationsdateien gab es ganz ungewöhnliche Probleme mit dem Kompilieren bzw. Deployen der Projekte. Vor allen Dingen Projekte, die ich schon zum Laufen gebracht hatte, als auch die generierten Projekte aus den POM-Dateien wurden vielfach nicht übersetzt oder konnten nicht auf den Tomcat depoyed werden. Teils gingen auch die SSI-Dateien mit den Tag-Libs, aber alleine die Existenz einer Java-Datei im Projekt hat die Übersetzung blockiert. Nicht einmal als Bean oder Controller gebaut, sondern eine leere Klasse im source-Verzeichnis hat genügt, um einen Fehler zu erzwingen.
Andere Projektkonfigurationen haben die Java-Controler und -Beans übersetzt, aber die xhtml-Dateien wurden auf dem Server nicht geparst und damit die Tag-Libs nicht verarbeitet.
In Netbeans gab es bei dem Problemen mit dem Java-Code die unverständige Fehlermeldung, dass source in der Version 6 nicht mehr unterstützt wird und wir die Version 7ff nehmen sollten. Nach diversen Problemen habe ich auf mein Matebook als Ursache getippt, aber auf dem Teilnehmerrechner waren die Fehler exakt reproduzierbar.
Irgendwann hatte ich die Faxen dicke und habe auf einem alten Linux-Rechner die Geschichte von Grund auf neu aufgesetzt. Also zuerst Maven, was noch nicht da installiert war, und dann einen Architype für JSF mit der Konsolenanwendung mvn aus dem Internet gezogen. Damit hat die Sache von A bis Z funktioniert und mir ist aufgefallen, dass ich auf dem Linux-Rechner das OpenJDK 8 installiert habe. Auf unseren beiden anderen Rechnern allerdings das JDK 16 und bei meinem Teilnehmer das JDK 15. Und danach haben wir endlich in einer Konfigurationsdatei zu den JSF 2.3 die XML-Tags gefunden, dass die Entwickler- als auch Zieldatei auf Java 8 festgelegt ist.
Unter dem Gesichtspunkt macht auch die Fehlermeldung von Netbeans Sinn – es müsste bei mir eigentlich heißen source in der Version 16, aber das Feld für die Versionsnummer wurde wohl nur einstellig konzipiert. Aus der 16 wurde die 6 und damit eine vollkommen unsinnige Fehlermeldung. Aber zum Zeitpunkt, wo die JSF 2.3 konzipiert wurden, hatte man vermutlich nicht an Inkompatibilitäten in so hohen Folgeversionen, sondern nur älteren Versionen, gedacht. Wir sind nicht so ganz sicher, ob die JSF bis zur Version 2.3 mit den neuen JDK nicht mehr klar kommen, aber ich denke schon. In der Doku steht explizit auch die Version 8. Das deckt sich mit der Tatsache, dass Cordova auch nur bis zur JDK-Version 8 funktioniert. Das habe ich ja in meiner Vorlesung an der TH Bingen die Tage behandeln müssen.
Die JSF werden wohl als Apache MyFaces weiterentwickelt und stehen mittlerweile in der Version 4.0 zur Verfügung, aber die haben wir uns dann nicht mehr genauer angesehen.

Rund um das Thema habe ich auch noch ein paar nützliche Anleitungen gefunden:

JSF Tutorial
https://www.javawebtutor.com/articles/jsf/
https://www.tutorialspoint.com/jsf/jsf_overview.htm

JSF in Tomcat zum Laufen bringen
https://www.byteslounge.com/tutorials/how-to-configure-jsf-in-tomcat-example

Webanwendungen als Docker-Images herstellen
https://jaxenter.de/apache-tomcat-meets-docker-webanwendungen-als-docker-images-herstellen-23213

Grundsätzlich hat sich mein Eindruck gefestigt, dass im Web Java nicht (mehr) der Bringer ist. Irgendwie reihen sich JSF/MyFaces in andere Projekte wie JavaFX/OpenJFX oder auch Cordova ein, bei denen die Originalhersteller die Entwicklung abgetreten haben und wo es aus meiner Sicht nicht sicher ist, dass diese Projekte auf Dauer sich halten und/oder zuverlässig weiterentwickelt werden.

Wobei die Erstellung eines Spring-Microservice für Tomcat wirklich genial einfach war und die mit einer Anleitung erstellte Version des Microservice absolut flexibel und einfach an beliebige Bedürfnisse anzupassen ist.

Das zweite Videotraining zu Maven wurde veröffentlicht

Maven für Fortgeschrittene - Multi-Module-Build-Automatisierung, Plug-ins und Profile erstellen, Unit-Testing
Maven für Fortgeschrittene

Bereits Ende letzten Jahres wurde Teil 1 meiner beiden Trainings zu Maven bei Video2Brain veröffentlicht. Jetzt ist Teil 2 – Maven für Fortgeschrittene -Multi-Module-Build-Automatisierung, Plug-ins und Profile erstellen, Unit-Testing da. In Multi-Module-Projekten werden verschiedene Module in einem übergeordneten Maven-Projekt zusammengeführt, was entweder mittels Vererbung oder mittels Aggregation der Module erfolgen kann. In diesem Video-Training gehe ich darauf ein. Dabei ist dieses Video-Training – wie auch Teil 1 – eine Adaption eines amerikanischen Lynda-Trainings.