Im privaten Bereich bin ich von Java auf Go gewechselt. Auslöser ist, dass die Arbeit mit KI die Softwareentwicklung auf den Kopf gestellt hat. Was früher Nachschlagen, Boilerplate und viel Tippen war, erledigt ein Assistent heute in kurzer Zeit. Übrig bleibt die Frage, ob man das Ergebnis versteht, prüfen kann und später noch ändert.

Dass sich der Alltag dadurch verändert, habe ich Anfang September schon beschrieben. Hier geht es um die Folge für die Wahl der Sprache im Backend: Go auf der einen Seite, Java mit Spring Boot oder Quarkus auf der anderen. Die Punkte habe ich für mich neu geordnet. Es sind Überlegungen aus der eigenen Arbeit, keine Messreihe.

Auf dev.neitzel.de habe ich beschrieben, was Large Language Models sind und wie sie arbeiten. Das bleibt Theorie, solange man die Maschine nicht selbst laufen sieht. Deshalb habe ich dieselbe Arbeitsweise in einem kleinen Go-Projekt umgesetzt: MinimalesLLM.

MinimalesLLM ist ein winziges neuronales Netz. Es trainiert auf einer normalen CPU, ohne Grafikkarte und ohne großes Rechenzentrum. Die Texte sind keine Sätze und keine Dialoge, sondern einzelne kurze Wörter, Vornamen, Buchstabe für Buchstabe. Das Netz lernt, welches Zeichen als Nächstes wahrscheinlich folgt, hängt dieses Zeichen an und macht weiter, bis das Wort zu Ende ist. Wer einen Anfang vorgibt, bekommt eine Fortsetzung. Ohne Anfang zieht das Programm selbst ein neues kurzes Wort.

Die Softwareentwicklung hat sich in den letzten Monaten spürbar verändert. Nicht nur ein bisschen an der Oberfläche, sondern im Alltag: Was früher Nachschlagen, Boilerplate, erste Entwürfe und viel Tipparbeit war, übernehmen heute oft moderne Werkzeuge – vor allem Large Language Models und die Assistenten, die darauf aufbauen.

Damit verändert sich auch das Berufsbild. Wer Software baut, muss weiterhin verstehen, was entstehen soll, welche Architektur trägt und ob das Ergebnis stimmt. Aber immer mehr der konkreten Arbeit dazwischen wird direkt von Tools erledigt. Syntax, typische API-Aufrufe, Testskelette, Umformulieren, Erklären von fremdem Code: Das ist nicht mehr der Engpass, der es früher war.

MVVM ist aus meiner Sicht für Desktop Anwendungen mit die beste Lösung, da die UI deklarativ erstellt wird und damit gut vom Model getrennt ist. Hier war in der Vergangenheit die Library mvmFX eine sehr gute Unterstützung, jedoch hat diese zuletzt vor einigen Jahren ein Update bekommen, so dass eine produktive Nutzung eher problematisch ist.

Daher macht es Sinn, einfach einmal zu schauen, wie eine MVVM Anwendung prinzipiell aufgebaut ist und wie man hier ggf. mit ein paar wenigen Klassen eine deutliche Vereinfachung herbeiführen kann.

Im Java-Forum wurde kürzlich die Frage gestellt, wie man bei JavaFX in Verbindung mit dem FXMLLoader Controller verwenden kann, die Konstruktorparameter benötigen.

Die Fragestellerin stand vor folgendem Problem: Der Controller einer FXML-basierten UI benötigt bereits in der initialize-Methode Zugriff auf bestimmte Objekte, die von außen übergeben werden müssen. Damit diese Objekte zum Zeitpunkt der Initialisierung verfügbar sind, wäre es naheliegend, sie über den Konstruktor einzuschleusen.

Anstatt jedoch sofort auf die Lösung „Konstruktor mit Parametern“ zu springen, lohnt es sich, einen Blick auf die verschiedenen Wege zu werfen, über die man Daten in einen JavaFX-Controller einbringen kann. Dabei ist der zeitliche Ablauf entscheidend: Wann findet was genau statt?