Java – Seite 2 – RJS-Blog – Ralph Steyer

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.

Aktualisierung meines Trainings zu den Neuerungen von Java

Bei LinkedIn Learning habe ich ein Training am Start, das sich um die Neuerungen der verschiedenen Versionen von Java kümmert. Bekanntlich erscheinen neue Versionen von Java mittlerweile alle 6 Monate und deshalb wird dieses Training immer wieder erweitert bzw. auf den neuen Stand gebracht. Derzeit behandle ich in diesem Training die Neuerung von Java 14, 15 und 16. Die Neuerungen der Version 17 spiele ich Ende dieser Woche neu ein und dann wird das Training noch einmal aktualisiert/erweitert und auf eine Art „Endstand“ gebracht. Denn die Version 17 ist nach vielen Jahren wieder eine LTS-Version, die in der Praxis auf viele Jahre die relevante neuste Version bilden wird. Wie der Name LTS – Long-Term-Support – aussagt, werden nur diese Versionen explizit über einen langen Zeitraum unterstützt. Während private Programmierer gerne schnell auf neue Versionen umsteigen, wird man in der professionellen Programmierung bzw. bei Business-Anwendungen fast immer nur solche LTS-Versionen berücksichtigen.

Java 17 LTS

Es ist fast erschreckend, wie lange ich mich mit Java schon beschäftige. Über 25 Jahre, denn ich habe Java kennengelernt, als es noch in der ersten Betaversion war. Auch wenn mittlerweile andere Sprachen Java für mich (aber auch allgemein wohl) etwas in den Hintergrund gedrängt haben, bin ich dennoch immer noch bei der Sache. Insbesondere verfolge ich die Neuerungen von Java über die letzten Jahre genau. Wobei dessen halbjährlicher Aktualisierungszyklus in meinen Augen nicht gut ist. Jede neue Version treibt irgendwelche Säue als Previews durch das Dorf und dann kommen die erst mehrere Versionen später oder auch gar nicht.

Aber mit der gerade erschienenen Version 17 gibt es einen Meilenstein, unter dem die vielen kleinen Neuigkeiten seit Java 11 nun einen festen Stand bekommen. Denn Java 17 ist die erste LTS-Version seit Java 11, der mit Java 8 die vorige LTS-Version voran ging. Die großen Unternehmen beachten ja meist nur die LTS-Versionen und wenn man die Entwicklung von Java betrachtet, ist es wohl auch nur sinnvoll, auf diese LTS-Versionen umzusteigen. Es sei denn, man ist ein Early-Adapter und/oder an den jeweiligen Neuerungen im Halbjahresturnus wirklich interessiert.

So gesehen ist also nach einigen Jahren gerade wieder eine Version erschienen, die sich vermutlich großflächig etablieren wird und von allgemeinem Interesse sein sollte.

Das war es mal wieder

Ich bin fertig mit meiner Aufnahmesession für LinkedIn Learning. Ich habe ein Training rund um Neuheiten bei Java auf den neusten Stand gebracht, bei dem mittlerweile zwei Versionsupdates erfolgt sind, und ein vollkommen neues Training eingespielt. Dabei stehen Kryptografie und Steganografie mit Python sowie diverse Themen rundherum im Fokus.

In der letzten Zeit hatte ich oft Adaptionen von Trainings gemacht oder Trainings zu Themen, die von LiL an mich herangetragen wurden. Und natürlich meine Serie mit wöchentlichen Entwicklers-Tipp zu Python.

Aber das neue Training ist vollkommen auf meinem Mist gewachsen. Ich hatte irgendwann die Idee, mich mit dem Thema aus Sicht von Python zu beschäftigen und dann aus Lust und Laune ein paar Scripts vor mich hinprogrammiert. Nachdem ich diese Scripts fertig hatte, kam mir die Idee, dass man daraus doch ein komplettes Training machen könnte. Mehr dazu kommt, wenn das Training produziert und veröffentlicht ist.

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.

Java 16 ist da

Die Version 16 von Java wurde gerade freigegeben. Seit der Einführung von Java 10 im Jahr 2018 verfolgt Oracle einen halbjährlichen Release-Plan. Damit soll man schneller auf Neuerungen im IT-Umfeld reagieren können. Ich persönlich finde die permanenten neuen Versionen allerdings nervig bzw. lästig. Die jeweiligen Neuerungen sind oft nur unter der Oberfläche, eher von kleiner Natur oder werden groß angekündigt und dann doch nicht implementiert. Das habe ich oft genug bei den letzten Versionen mitbekommen.

Aber sei es drum – auch wenn ich mich immer noch als Fan von Java sehe (vor allen Dingen den frühen Versionen), mache ich mit Java die letzten Jahre nicht mehr wirklich viel. Hin und wieder ein paar Online-Training für LiL (LinkedIn Learning) oder das Buch „Jetzt lerne ich Java“ von MuT. Aber irgendwie hat Java für mich ein wenig seinen Reiz verloren und auch die Anfragen für Schulungen oder Projekte im Java-Umfeld haben bei mir exorbitant abgenommen. Java fällt bei mir mittlerweile vor allen Dingen bei Schulungen zugunsten von Python fast komplett hinten runter. Was erstaunlich ist, denn Java war für viele Jahre neben clientseitiger Web-Programmierung meine Hauptsäule.

Was zu dem Fazit führt, dass ich gerade für April eine Java-Einzelschulung angenommen habe. Logisches Fazit, oder? 🙂

Vorteile und Graus der Virtualisierung – Docker & Co

Cordova

Da ich für das kommende Sommersemester an der Technischen Hochschule Bingen wieder einen Lehrauftrag zum Thema Cordova und plattformneutrale App-Entwicklung angenommen und gerade Zeit für die Vorbereitung habe, habe ich die letzten Tage in den aktuellen Stand von Cordova reingeschaut und meine alten Projekte und Matrialien zusammengetragen. Ich hatte dieses Thema eine ganze Weile schleifen lassen, da Python, Big Data, Web-Programmierung, Cobol, C# & „Was auch sonst immer“ die Arbeit in eine andere Richtung gelenkt hatten.

Die meisten Dinge, die ich die vergangenen Jahre zusammengestellt und programmiert habe, sind jedoch noch weitgehend auf Stand. Allerdings haben sich auch durchaus Sachen geändert. Daher bedarf die neue Vorlesung einiger Vorbereitung und eine Anpassung.

Zudem habe ich auch ganz einfach Lust, meine ganzen Apps zu aktualisieren. Parallel will ich aus einigen Apps Python-Programme machen. Ohne konkrete Ziele, aber vielleicht kommen mir dabei ein paar neue Ideen und ich lerne natürlich was dazu – auch wenn das im Grunde aktuell ein reines Programmieren aufgrund von Zeit und Lust darstellt.

Anyway – bei Cordova gibt es ein paar Sachen, die mich schon stutzig gemacht und zu einigen Arbeiten im Hintergrund sowie grundsätzlichen Überlegungen genötigt haben. Das reine Installieren der neuen Version von Cordova mit npm geht wie gehabt und das Erstellen von Cordova-Projekten in dem Cordova-CLI auch. Ebenso das Hinzufügen der verschiedenen Plattformen und das Ausführen in dem Browser-Emulator ist unverändert. Die eigentlichen Quellcodes auf Basis von JavaScript & Co sowieso.

Aber wenn man etwa beim konkreten Kompilieren Android als Plattform für die Cordova-Apps haben will, wird das JDK 8 vorausgesetzt. Im Moment ist aber schon das JDK 15 aktuell und damit funktioniert es nicht. Zumindest bekomme ich es im Moment nicht hin, mit der derzeit aktuellen Java-Version Android-Apps zu erstellen. Ehrlich gesagt ist mir nicht einmal klar, ob das an Android (da soll ja Java auch sukzessive abgelöst werden) oder Cordova liegt. Wie angedeutet, habe ich die App-Entwicklung eine Weile aus den Augen verloren.

Und dann hatte ich das Android Studio bzw. das Android SDK als auch Xcode komplett von meinen Rechnern gelöscht, da ich eben das Entwickeln für Android und iOS die letzte Zeit nicht gebraucht hatte. Zumal ich mich sowieso auch dabei auf das Visual Studio committed hatte. Dabei kann man ja wunderbar auch Android- bzw. iOS-Apps erstellen.

Aber um die verschiedenen Möglichkeiten im Vorfeld der Vorlesung mal wieder auszutesten, werde ich auf meinem Mac vermutlich Xcode neu installieren (wenn ich die Sache mit meiner Apple-ID geklärt habe – die habe ich auslaufen lassen) und das Android Studio habe ich mittlerweile wieder neu installiert.

Aber irgendwie hat es bei meinem ersten naiven Versuch nicht funktioniert, damit Cordova-Projekte zu öffnen – oder besser – zum Laufen zu bringen. Irgendwie mag ich das Android Studio aber auch nicht wirklich. Ich sollte der Sache zwar auf den Grund gehen, aber ich werde ja sowieso Visual Studio nehmen.

Wobei es da auch ein seltsames Problem gibt. In Visual Studio 2019 ist die Erweiterung für Cordova nicht mehr dabei und damit kann man weder Cordova-Projekte anlegen noch vorhandene Cordova-Projekte öffnen. Also musste ich die schon gelöschte Version 2017 von Visual Studio mit der Cordova-Erweiterung wieder auf meine Rechner aufspielen. Damit geht aber alles wunderbar und ich habe mittlerweile diverse Cordova-Apps erstellt, aus Visual Studio in verschiedenen Emulatoren sowie per USB-Debugging sogar direkt auf mehreren Geräten ausgeführt. Auch die Installation auf ein paar Testgeräten funktioniert problemlos. Seltsam sind die Begleiterscheinungen jedoch schon und ich bin nicht sicher, ob Cordova noch lange auf dem Markt bleibt. Was Cordova aber nicht als gute Basis für die kommende Vorlesung diskreditiert, um grundsätzlich die Erstellung von plattformneutralen Apps auf Basis von Webtechnologien zu lernen. Denn im Umfeld von Xamarin sind die gleichen Bedingungen/Probleme vorzufinden. Die Frage ist also wohl eher, ob Apps auf Basis von Webtechnologien sich auf Dauer etablieren oder nicht?

Wie dem auch sei – ich habe eigentlich keine Lust, das alte JDK 8 auf meine Rechner zu installieren und auch nicht die ganzen Emulatoren und SDKs von Android Studio auf Teufel komm raus zu konfigurieren. Entweder es geht „out-of-the-box“ wie bei Visual Studio 2017 oder die Sache kann mir im Grunde gestohlen bleiben. Es geht mir um die eigentlich Programmierung innerhalb des Cordova-Wrappers mit JavaScript und HTML/CSS und nicht um das Geraffel rundherum. Das hat mich schon immer an der App-Programmierung genervt.

Und da kam ich auf die Idee, eine andere Sache mal wieder aufzugreifen, die ich vor einigen Monaten angefangen, dann aber wegen anderer Dinge – wie so oft – beiseite gelegt habe: Docker.

Warum nicht einfach ein gut konfiguriertes Docker-Image für Cordova laden und dann ohne das ganze Installieren und Konfigurieren die Apps bauen? Das war meine Idee. Sollte doch einfach sein.

Und wie immer, wenn etwas auf den ersten Blick so einfach und logisch aussieht, steckt der Teufel im Detail. Genau genommen sind es in dem Fall sogar gleich mehrere Teufel gewesen.

Denn obwohl ich mich schon mit Docker beschäftigt und auch schon Images bzw. Container zum Laufen gebracht hatte, habe ich das Zeug zwischenzeitlich wieder von meinen Rechner gelöscht gehabt. Also musste ich Docker erst einmal „schnell“ installieren. Was (natürlich) wieder gar nicht schnell war und letztendlich sogar auf meinen Windows-Rechnern gescheitert ist. Weder unter Windows 10 Pro noch unter Windows 10 Home ist Docker bei mir richtig gelaufen. Natürlich kam ich bei den Problemen mit Windows 10 Pro sofort auf Hyper-V und diesen ganzen Virtualisierungs-Kram im Hintergrund von Windows, denn damit habe ich schon seit Jahren Ärger im Zusammenspiel mit VirtualBox und dem VMWare Player. Und auch wenn der VMWare Player ab der Version 16 wohl mit dem Hyper-V-Geraffel kann und auch Docker in Windows 10 Pro irgendwas mit Hyper-V macht und ich die Anleitungen für die ganzen Einstellungen umgesetzt habe, hat das Zeug irgendwelche Probleme mit den Rechten. Dazu kommt – bei Windows 10 Home gibt es ja kein Hyper-V und da muss man dann andere Sachen konfigurieren bzw. installieren. Alles doch ein elendes Gefuddel, was ich ja ausdrücklich vermeiden wollte und ich habe nach diversen Versuchen die Lust verloren.

Also auf meinen Linux-Rechner gewechselt, auf dem Docker erwartungsgemäß problemlos läuft. Zwischenzeitlich war ich auch in Eppstein und habe Docker mal auf meinem iMac getestet – auch keine Probleme. Also Docker sollte doch ein lohnenswerter Ansatz sein.

Aber dann bin ich auf das nächste blöde Problem gestoßen, erst einmal ein geeignetes Cordova-Image für Docker zu finden. Auf Git gibt es da was, aber der Git-Zugriff scheitert durch Rechteprobleme. Das Image scheint entweder gesperrt oder verschoben worden zu sein. Dann habe ich noch eine Anleitung gefunden, wie ich mir selbst ein Cordova-Image erstellen kann, aber das ist ja das Gegenteil von dem, was ich eigentlich wollte – keine Arbeit mit der blöden Konfiguration. Letztendlich habe ich nur ein Docker-Image gefunden, dass (angeblich) mit einem einfache Pull vom Docker Hub zu installieren wäre. Also so (vermutlich als root notwendig):

sudo docker pull beevelop/cordova:latest

Das Starten des Image soll dann einfach so funktionieren:

sudo docker run -it beevelop/cordova bash

Unter Windows habe ich wie gesagt Docker nicht stabil zum Laufen gebracht und das Image wurde angeblich nicht gefunden. Beim iMac muss ich es noch probieren, aber auf meinem Linux-Rechner ging der Pull einwandfrei. Bis 98% durch waren. Dann kam reproduzierbar immer wieder der Abbruch.

Mittlerweile war es Krieg – die Technik gegen mich. Oder umgekehrt. Und wenn etwas einfach nicht laufen will, werde ich zum Berserker. Auch wenn im Grunde alles Notwendige zur Vorlesung über Cordova mit Visual Studio bereit gestanden hat – ich lasse mich doch nicht von so einem Mist in die Knie zwingen.

Mein Mint Linux-Rechner ist noch in der Version 19 und das System wollte ich auch nicht verpfuschen. Von daher kam mir die Idee, meine Linux-VM (Mint Linux 20) unter Windows 10 zu verwenden. Nur konnte die plötzlich auf meiner Workstation mit VirtualBox nicht mehr gestartet werden und auch die Installation einer neuen Linux-VM ist gescheitert. Möglicherweise aufgrund der Hyper-V-Einstellungen und dem Kram, aber ich hatte einfach keinen Bock mehr auf das Gefummel. Also eine neue Version von VMWare-Player aufgespielt, dort eine Version von Mint-Linux 20 installiert und da ging dann der Pull des Docker-Images. Ohne Probleme. Wenn man „Von hinten durch das Auge“ wortwörtlich haben will, ist das diese Konstruktion – eine Virtualisierung in einer Virtualisierung.

Wer aber jetzt glaubt, die Sache wäre vorbei, täuscht sich. Denn in dem Cordova-Image war kein passendes JDK 8 dabei. Die Erstellung eines Cordova-Projekts ging damit problemlos, aber das geht ja auch in meiner normalen Cordova-CLI und damit bringt mich ein Docker-Image keinen Millimeter weiter. Als ich eine Android-App kompilieren wollte, war war auch im Docker-Container Schicht im Schacht.

Aber es war mittlerweile schon lange persönlich und jetzt wollte ich es durchziehen. Also in dem Docker-Container das JDK 8 nachinstalliert. Das geht so:

apt-get update && apt-get install -y openjdk-8-jdk && apt-get install -y ant && apt-get install -y gradle && apt-get clean

Unter Umständen tut ein Update der Zertifikate noch gut (bei mir nicht notwendig gewesen):

apt-get update && apt-get install ca-certificates-java && apt-get clean && update-ca-certificates -f

Und letztendlich müssen u.U. die Umgebungsvariablen gesetzt werden (bei mir auch nicht mehr notwendig gewesen):

ENV JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64/

oder

set JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64/

und dann:

export JAVA_HOME

Danach konnte ich endlich eine Android-App im Docker-Container kompilieren. Nur sind Docker-Systeme ja flüchtig und wenn der Docker-Container beendet wird, sind alle Änderungen samt der gespeicherten Daten weg. Also waren Snapshots des aktuellen Stands notwendig. Das geht aus einem zweiten Terminal heraus etwa so:

sudo docker commit -p 532a5b3584e8 container1

Dabei braucht man die ID oder den Namen des Docker-Containers.Bekommt man so:

sudo docker ps

Dann bekommt man was der Art angezeigt:

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
532a5b3584e8 container1 „bash“ 19 minutes ago Up 19 minutes eloquent_liskov

Und dann muss die kompilierte App ja auch noch raus aus dem Docker-Container oder man muss was reinkopieren. Also stellte sich die Frage, wie man aus einem zweiten Terminal aus dem Clientsystem auf den Host rauskopiert oder umgekehrt? Das geht formal so (wieder mit sudo):

docker cp <SRC> <DEST>

Also konkret was der Art (in den Container):

sudo docker cp /home/ralph/Schreibtisch/www eloquent_liskov:/tmp/HalloWelt
sudo docker cp /home/ralph/Schreibtisch/rjsedv.jks eloquent_liskov:/tmp/HalloWelt
sudo docker cp /home/ralph/Schreibtisch/build.json 532a5b3584e8:/tmp/HalloWelt

Aus dem Container auf den Host geht für die generierte Android-App etwa so:

sudo docker cp eloquent_liskov:/tmp/HalloWelt/platforms/android/app/build/outputs/apk/debug/app-debug.apk /home/ralph/Schreibtisch

Die späteren Neustarts der Snapshots zeigten, dass noch (weitgehend) alle Daten waren und jetzt schien alles ok.

Pustekuchen. Denn auf meinem Notebook mit Windows 10 Home konnte der VMWare-Player die virtuelle Maschine nicht starten, die ich auf der Workstation erstellt hatte. Und ist auch beim Neuinstallieren eines Linux-Systems gescheitert. Irgendwas mit der Anzeige ging schief. Warum auch immer.

Also habe ich auf dem Notebook VirtualBox genommen, denn das ist dann dort im Gegensatz zum VMWare Player auch mit Linux als Clientsystem sauber gelaufen. In der damit erzeugten VM für Mint-Linux 20 das ganze Zeug mit Docker nochmal gemacht und das hat dann auch funktioniert.

Letztendlich hat das „Mal schnell“ zu gut einem vollen Tag Arbeit geführt, aber ungelöste Probleme lassen mir keine Ruhe und ich habe dabei vor allen Dingen wieder eine Menge gelernt. Vielleicht kann ich das neue Wissen ja nochmal brauchen.

Update: Irgendwann habe ich dann festgestellt, dass das Docker-Cordova-Image die Cordova-Version 9 verwendet hat und mittlerweile die Version 10 aktuell ist. Was im Grunde nicht schlimm ist, aber so kann man das dann im Container noch aktualisieren:

npm i -g cordova to update

Die nächsten zwei neuen Videotraining sind freigegeben

Da bin ich doch gerade erst mit meinen aktuellen Aufzeichnungen fertig und dann fällt mir eben beim Besuch der Seiten von LinkedIn Learning auf, dass vor einer Woche gleich zwei neue Videotraining bei LiL freigegeben wurden.

Das eine Training ist JavaScript: In HTML 5 arbeiten.

Dabei geht es darum:

HTML und JavaScript zusammen bieten für alle Webprogrammierer das optimale (Programmier-)Sprachendoppel, wenn es um die Entwicklung moderner Webauftritte geht. Tatsächlich laufen viele Features, die unter HTML5 geführt werden, in Wirklichkeit unter JavaScript: Manchmal gehen sie zwar mit neuen HTML-Tags einher, andererseits gibt es oft nicht einmal eine zwingende Verbindung zu HTML. In diesem Video-Training werden ein paar anschauliche Beispiele zusammengetragen und der optimalen Code gezeigt, wenn es um Techniken wie Geolocation, Local Storage und Session Storage, Web Worker, Canvas oder auch SVG samt der dynamischen Manipulation geht. Auch Web Sockets als Grundlagen mächtiger Rich Internet Applications lernen Sie im Laufe des Kurses kennen.

Der zweite Kurs behandelt Java. Genau genommen geht es um die Neuerungen von Java 14.
Kursdetails – Java feiert im Jahr 2020 seinen 25. Geburtstag – und zählt immer noch zu den populärsten und wichtigsten Programmiersprachen. Da inzwischen neue Versionen im gefühlt halbjährlichen Turnus erscheinen, tut rechtzeitige Aufklärung Not. Ich habe mir für den Kurs Java 14 angeschaut und die wichtigsten Neuerungen in diesem Übersichtskurs zusammengefasst. Sie lernen zum Beispiel relevante Syntaxneuerungen kennen, sehen, wie Sie TextBlocks und Records nutzen und erfahren auch mehr zu den Erweiterungen des instanceof-Operators. Im Kontext stehen auch immer ältere Versionen und ein Blick in die Zukunft von Java.

Die Videotraining sind im Kasten

Was war das dieses Mal eine umfangreiche Aufzeichnungssession. Insgesamt 4 komplette Training mit ganz viel Stoff zu JavaScript und ein wenig Stoff zu Neuerungen bei Java. Ein

superlanges Training mit über 5,5 Stunden Rohmaterial,
ein langes,
ein kurzes und
ein ganz kurzes Training

sind da raus gekommen. Mal sehen, wann die Videoaufnahmen bei LinkedIn Learning veröffentlicht werden. Und weitere Aufnahmen sind schon angesetzt. Aber vorher halte ich erst einmal wieder Schulungen. Zuerst 3 kurze Remoteschulungen zu Python und passenden Frameworks, aber ab Mitte Juni sollen sogar in der Tat Vor-Ort-Schulungen zu C# laufen. Ich bin gespannt, ob das wirklich durchgezogen oder verschoben oder auch auf Remote umgestellt wird.

Für meinen letzten Aufnahmetag bin ich gestern mit meinem neuen Spielzeug (das Trek Procaliber) wieder von Bodenheim nach Eppstein zum „Aufnahmestudio“ geradelt. Heute morgen ging es zurück und unterwegs kam mir die „aberwitzige“ Idee, dass ich mir für den Rückweg eine Zeit unter 1,5 Stunden als Ziel für das Jahr setzen sollte. Ich bin heute nur mit halber Kraft gefahren und habe sogar eine ganz kurze Pause gemacht, aber die vermutlich schnellste Strecke für die Tour ausgewählt. Die Route läuft recht gut und mir schien es möglich, dass man es bei optimalen Bedingungen (gutes Wetter, körperlich richtig fit, nirgends groß durch Ampel etc. aufgehalten) es wirklich unter 1,5 Stunden schaffen könnte (zumal ich letzte Woche mit 1:38 für die Strecke Eppstein-Bodenheim einen neuen Rekord aufgestellt hatte – wenngleich eine etwas andere Route).

Dieses Ziel muss ich jedoch leider aufgeben – denn ich habe heute schon nur 1:29 gebraucht. Unglaublich, weil da definitiv noch Luft nach oben ist. Sowohl von den Pausen als auch meiner eingesetzten Power. Ob das neue Rad wirklich so viel ausmacht?

Oder werde ich in der Tat langsam bei meinen Ausdauerwerten fitter? Die elenden Corona-Einschränkungen haben die letzte Zeit dazu geführt, dass meine 2 – 3 Krafttraining / Woche weggefallen sind. Stattdessen bin ich viel mehr gejoggt oder eben Rad gefahren. Statt bisher vielleicht 1x/Woche Joggen (wenn überhaupt) und 2x/Woche Radfahren als Ergänzung zu dem „normalen“ Training bin ich jetzt schon ein paar Wochen so gut wie täglich entweder am Laufen oder Radfahren. Over all habe ich im Corona-Gefängnis damit zwar 6x – 7x / Woche trainiert, aber auch vor Corona war ich mit mindestens 4 – 5 Training / Woche nicht so viel weniger aktiv. Nur halt mehr Richtung Kraft und Beweglichkeit und jetzt eben fast nur noch Ausdauer. Auch wenn ich hoffentlich bald wieder mehr Krafttraining und Gymnastik machen kann, versuche ich die Ausdauer auch in Zukunft mehr zu trainieren, was meinem Gewicht gut tun sollte. Der Anfang, der immer am schwersten ist, ist ja gemacht. Leider gingen die letzten Wochen aber sicher auf Kosten meiner Kraftwerte, die eigentlich nach dem Winter auf einem Stand wie zu meinen besten Zeiten waren.

Der Trailer und ein paar Videos zu meinem neuen Traininig bei LinkedIn

Hier sind ein paar Eindrücke von meinem neuen Training zu den Neuerungen der Java-Versionen 8 – 12 bei LinkedIn Learning.

Willkommen zu dem Video-Training „Java 12: Ein erster Blick“ aus Java 12: Ein erster Blick von Ralph Steyer

Kompilierungslevel einstellen aus Java 12: Ein erster Blick von Ralph Steyer

Kostenlose Beispielfilme:

Die folgenden Videos sind ebenfalls frei geschaltet:

Worum geht es bei Jigsaw?

https://de.linkedin.com/learning/java-12-ein-erster-blick/worum-geht-es-bei-jigsaw

Module deployen

https://de.linkedin.com/learning/java-12-ein-erster-blick/module-deployen

Neuer Onlinekurs: Java 12: Ein erster Blick

Da ist doch gerade wieder einen neues Training von mir bei LinkedIn Learning erschienen und ich habe das nur indirekt mitbekommen – über den Post von meinem Content-Mangager bei LinkedIn. Das erklärt auch eine Mail mit einer Frage unter Bezug auf mein neues Training zu Java 12. Die hatte ich gestern beantwortet, aber nicht so ganz geblickt, dass es um das neue Training von mir im Bezug gegangen war. Es geht in dem Training umd einen kurzen Überblick zu den Java-Version 8.0 bis 12.0. Seit Java im Jahr 1996 das Licht der Welt erblickte haben die einzelnen Versionen immer wieder Standards gesetzt und nach wie vor zählt Java zu den erfolgreichsten und verbreitetsten Programmiersprachen. Während früher jedoch zwischen den verschiedenen Versionen oft geraume Zeit verging und diese auch unregelmäßig erschienen sind, gibt es seit Java 10 neue Versionsnummern im halbjährlichen Turnus. Diese Video-Training stellt Java 12 in den Mittelpunkt, wobei der Überblick auch die wichtigsten Neuerungen der immer noch sehr verbreiteten Versionen 9, 10 und 11 erfasst.

Java trifft Mathematik

Das war es jetzt aber. Gerade ist auch das letzte Videotraining der Serie veröffentlicht worden, die ich im Laufe dieses Frühjahrs aufgenommen habe.
Auch das Training mit dem Titel Java: Rekursion – Konzepte und Lösungen ist eine Adaption eines US-Trainings von Lynda/Linkedin.
In den letzten Monaten habe ich einige solcher Adaptionen aufgenommen. Das war aus verschiedenen Gründen reizvoll für mich. Vor allen Dingen, weil ich bis vor einigen Monaten immer nur rein selbst konzipierte Trainings aufgenommen hatte. Bei einer Adaption geht man vollkommen anders an die Sache ran und bekommt nach vielen Jahren wieder neue Blickwinkel und Anreize. Es ist ungefähr so als wenn man als Musiker über Jahre alle Stücke selbst schreibt und performed und auf einmal Stücke performed, die ein anderer Komponist geschrieben hat. Beides hat seine Reize – die Mischung macht es.

Aber zum konkreten Training: „Rekursion“ beschreibt die Vorgehensweise, bei der die Lösung eines komplexen Problems in Lösungen für kleinere Instanzen des gleichen Problems zerlegt wird, die dann wiederholt angewendet wird. In der Programmierung wird das durch Selbstaufrufe umgesetzt.
So etwas kommt oft bei der Umsetzung von mathematischen Fragestellungen zum Einsatz. Aber nicht nur da. Dennoch – das ist mal wieder ein Training, bei dem ich mir selbst bestätigen kann, dass mein Mathematik-Studium doch nicht ganz umsonst war und noch manchmal einen rudimentären Bezug zu meiner Arbeit hat. Aber man kann sich Dinge ja auch schön trinken ;-).
Anyway – dieses Video-Training überprüft Konzepte der Rekursion in der Programmiersprache Java, demonstriert verschiedene Problemlösungsansätze – zum Beispiel in der mathematischen Induktion – und zeigt zahlreiche rekursive Codelösungen.

Das zweite Videotraining zu Maven wurde veröffentlicht

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.

Wieder mal einen externen Auftrag erledigt

Die letzten drei Tage habe ich in Bochum geschult. Dabei bin ich schon am Sonntagabend angereist und rund um Köln war es wie immer eine Verkehrskatastrophe (will nicht wissen, wie das im Berufsverkehr ist). Ich war beruflich schon so oft in der Gegend (vor allen Dingen Dortmund und Düsseldorf), aber in Bochum noch nie (und privat auch nur 1x). Wobei ich mittlerweile eigentlich genug von Hotels habe. Über die Jahre bin ich soviel beruflich rumgekommen – ich bin um jeden Auftrag froh, den ich von zuhause oder im Rhein-Main-Gebiet erledigen kann. Aber wenn es nicht zu oft wird, dann gehe ich halt auch auf Tour. Man lernt so viele Gegenden kennen, die man privat vermutlich nicht sehen würde und „in maßen“ ist das dann immer auch eine nette Abwechselung.

Mein Klientel war eine Gruppe von Java-Entwicklern, die ich zu JavaFX geschult habe. Als Betriebssystem hatten wir im Schulungsraum Windows XP. Ich wiederhole – XP! Ich wollte es erst einmal nicht glauben, aber selbst im harten Praxiseinsatz wird bei dem Kunden (einer Versicherung) noch Windows XP gefahren. Grund ist eine Terminalemulation für den Host, die nicht weiterentwickelt werden kann (Anbieter pleite) und die in neueren Windows nicht läuft. Schon krass. Aber da zeigt sich wieder der Vorteil von Java. In einem extrem heterogenen Umfeld (Windows 2000, XP, 7 sowie Linux und Hostsystemen) gibt es keine wirkliche Alternative.

Was auch recht heftig war – die Schulungsrechner haben in dem Produktionsnetzwerk gehangen. Deshalb durfte ich weder etwas auf dem Rechner installieren noch eine USB-Stick verwenden noch irgendwelche Codes aus der Cloud ziehen. Statt vorbereiteter Beispiele war dann halt Live-Coding angesagt.

Kostenlose Beispielfilme und Trailer zu meinem neuen Video-Training „JavaFX-Diagramme mit Netbeans“

JavaFX-Diagramme mit Netbeans. Diagrammarten und -techniken, FXML, Diagrammdaten in Datenbank speichern. Mit Ralph Steyer

Die Tage ist ja mein Video-Training JavaFX-Diagramme mit Netbeans. Diagrammarten und -techniken, FXML, Diagrammdaten in Datenbank speichern erschienen.

Mittlerweile sind dazu auch eine Reihe an kostenlosen Beispielfilmen und der Trailer freigegeben worden.

Mein neuste Java-Buch ist erschienen

Jetzt lerne ich Java - Für Einsteiger und Fortgeschrittene - von Ralph Steyer — Jetzt lerne ich Java – Für Einsteiger und Fortgeschrittene – von Ralph Steyer

Mein neues Buch zu Java ist beim Verlag Markt+Technik erschienen. Das ist für mich ein „Back-to-the-roots“ in reinster Form. Mein aller erstes Buch habe ich zwar 1996 beim Data Becker Verlag veröffentlicht (zu HTML), aber bereits 1997 war ich dann bei Markt+Technik gelandet. Dort (und beim Schwesterverlag Addison-Wesley) habe ich über die Jahre dann zig Bücher veröffentlicht. Ich muss mal an mein Regal mit den Belegexemplaren gehen, aber es sollten um die 40 Bücher sein, wenn am alle Auflagen und Übersetzungen einzeln zählt. Auf jeden Fall eine Menge Holz (auch im eigentlichen Sinn), was mit Markt+Technik und Addions Wesley bedruckt wurde.

Der Mutterkonzern Pearson hatte nun vor wenigen Jahren den Vertrieb von EDV-Büchern und samt der beiden Buchverlage weitgehend eingestellt. Allerdings wurde Markt+Technik unter neuer Führung recht bald wieder belebt. Die Marke hat sich ja die über Jahre etabliert und von daher habe ich gerne zugegriffen, als ich das Angebot bekam, mein altes Java-Buch für Markt+Technik zu überarbeiten. Da ich dieses Thema aktuell nicht bei anderen Verlagen beackere, mache ich mir damit selbst keine (verbotene) Konkurrenz .

Wie gesagt – es geht zurück zu den Ursprüngen. Interessanter Weise auch bei diversen anderen Aufträgen (nicht nur beim Schreiben von Büchern). Es kommt immer alles wieder ….