JavaFX mvvmFX

[Ernesto95]

Moin Moin !

Ich habe bis dato meine FX Projekte immer mit einer (eigenen) Interpretation des MVC Patterns umgesetzt, stoße aber in Verbidung mit FX immer wieder auf das MVVM-Pattern. Dies wollte ich mir mal etwas genauer anschauen und bei meinem nächsten Pojekt verwenden.

Hierbei taucht auch immer die Bibliothek mvvmFX auf. Unter anderem auch @KonradN hier im Forum hat diese mehrfach auch in jüngster Zeit erwähnt. Ich zweifel nur ein bisschen daran mich in eine Bibliothek einzuarbeiten die seit exakt 5 Jahren keine Updates mehr erhalten hat.

Daher meine Frage, lohnt sich der Einstieg in mvvmFX, weil es komplett und fertig ist und daher seit Jahren keine Updates mehr bekommen hat. Oder ist das Projekt tot und man sollte sich in das MVVM-Pattern lieber ohne diese Bibliothek einarbeiten ?

Grüße Ernesto

 

[Oneixee5]

Ein Blick auf das Maven-Repo: https://mvnrepository.com/artifact/de.saxsys/mvvmfx/1.8.0 zeigt, dass eine alte Version von Logback verwendet wird, welche einen CVE enthält. Damit würde die Lib für eine Firma ausscheiden. Die Version von Logback ist so alt, dass diese vermutlich nicht einfach durch eine aktuelle Version ersetzt werden kann. Für den persönlichen Einsatz mag das noch funktionieren. Eine Anwendung mit bekannten CVE's würde ich aber nicht weitergeben wollen.

 

[Oneixee5]

Es gibt auch ein Ticket dazu: https://github.com/sialcasa/mvvmFX/issues/623 aus 01.2023. Das ist also älter als ein Jahr. Die Antwort ist deshalb keine gute Nachricht. Wenn nicht die Ressourcen vorhanden sind, um das Projekt regelmäßig zu pflegen, dann sollte es besser nicht eingesetzt werden. Das würde die eigene Investition gefährden.

 

[Ernesto95]

Danke, das Ticket ist sogar aus 01/22. Also wird da nicht mehr wirklich dran gearbeitet und für neue Projekte demnach nicht empfehlenswert :-/

 

[Oneixee5]

Falls dir das wichtig ist, kannst du das Projekt auch klonen und selbst auf den neuesten Stand bringen. Wenn du dann glaubst, das die Basis gut ist und es sich lohnen kann das Projekt weiterzuführen, kannst du beim Maintainer anfragen, ob du es weiterführen kannst oder möglicherweise ganz übernehmen.
Ich persönlich sehe eigentlich überhaupt keinen Bedarf oder Sinn an einem UI auf Java-Basis.

 

[KonradN]

Das Problem ist aus meiner Sicht ebenso, dass Java UIs kaum eine Rolle spielen und daher viele Projekte einfach nicht weiter geführt werden. Wenn, dann würde ich vermutlich auf ein Framework setzen, welches in anderen Projekten verwendet wird. Das, was mir da in den Sinn kommt, sind dann IntelliJ (Swing) und Eclipse (SWT / RCP).

Bezüglich der verwendeten Pattern ist MVVM aber unabhängig von der konkret verwendeten Library. Daher kann mvvmFX durchaus interessant sein, denn da ist sehr viel Dokumentation verlinkt. Die Library selbst kann man - wie schon gesagt - clonen um dann so Probleme zu beheben. Aber da ist wirklich die Frage, was für einen Sinn das macht. Vermutlich wird man nur einen relativ kleinen Bruchteil benötigen und es dürfte weniger Arbeit machen, entsprechende Teile selbst umzusetzen. Der große Aufwand bei mvvmFX ist ja gewesen, eine universelle Library zu entwickeln. Aber wenn man das universelle nicht braucht und auch etwas mehr Eigenanteil im Code akzeptiert, dann wird das deutlich weniger Arbeit machen. Das ist aber erst einmal eine Vermutung von meiner Seite.

Das ich mich mit mvvmFX beschäftigt habe ist halt auch schon einige Zeit her und der Einschätzung von @Oneixee5 kann ich aktuell nur voll und ganz zustimmen.

 

[Ernesto95]

Ne danke, ein solches Projekt zu leiten und am Leben zu halten, dafür reichen meine Fähigkeiten und meine Zeit als Hobby Programmierer bei weitem nicht aus. Aber ich werde mal ein bisschen im Quellcode stöbern und schauen wie da Sachen umgesetzt wurden.

Was mich aber immer wundert sind so Aussagen das Java im Desktop Bereich kaum eine Rolle spielt und UIs in Java demnach kaum gefragt sind. Mit Sicherheit ist Java hier nicht dee Marktführer, und ihr die ihr beruflich damit zu tun habt seit da näher dran.

Aber ich komme aus dem Speditionsbereich, und hier begegnen mir abseits des SAP Monsters und MS Office immer wieder Java Desktop Anwendungen. Von einfachen Insellösungen über komplexe Lager- / Containerverwaltungssysteme bis hin zu Scope von Riege, das mich jetzt seit mehr als 15 Jahren schon durch 3 Firmen begleitet.

 

[Oneixee5]

Ja gerade hier sind Desktop-Systeme mit einem starren UI im Nachteil. An einem Lagersystem sind oft sehr viele Personen mit sehr unterschiedlichen Tätigkeiten und Verantwortlichkeiten beteiligt. Es wird unterschiedlichste Hardware verwendet und alles muss im LKW, im Gabelstapler, im Kühlhaus genauso funktionieren wie im Büro. Man muss eine Software also für alle möglichen Geräte und Einsatzzwecke anpassen. Nichts ist da schwieriger als ein JavaFX-Desktop. Man packt sein Zeug in eine fette Datenbank, strikt ein Backend darum, sichert das Ganze entsprechend ab und kann dann in aller Ruhe mit allen möglichen Geräten die selben Schnittstellen zum Backend verwenden. Man muss sich keine sorgen machen, ob ein Smartphone in der Lage ist 100 Seiten PDF zu erzeugen, oder ein bulgarischer LKW-Fahrer deutsch lesen kann. Ich kann für alle die passende Oberfläche liefern und arbeite immer mit den selben Daten, ob Mobil oder Office.
Selbst im privaten Bereich. Eine Mail von meiner Versicherung oder meiner Cryptobörse sehe ich zuerst auf dem Smartphone. Also öffne ich die entsprechende App oder Webseite. Einfache Dinge kann ich da schnell erledigen. Anderes will ich mir evtl. erst mal in Ruhe durcharbeiten. Da will ich aber nicht alles auf dem Phone lesen. Ich nehme da eher das Tablett, Notebook oder den Desktop. Der Drucker steht bei mir zu Hause, den kann ich evtl. gar nicht über mein Phone ansteuern. Office will ich sowieso am Desktop machen. Alles hat aber irgendwie mit der Mail vom Anfang zu tun. Ich brauche also für eine Mail verschiedene Programme/Oberflächen/Geräte. Nichts ist da weiter weg als JavaFX. Am nächsten dran ist da aber eine "mobile first"-Web-Anwendung. Ob ich diese dann als progressive WebApp bereitstelle oder eine native App daraus kompiliere, oder eine DesktopApp daraus ableite ist wohl viel einfacher und effizienter. Auch wird der Anwender die Bedienung und das Aussehen immer wiedererkennen.
Ich nehme da immer meinen Lego-Shop als Beispiel. Steine mit dem Handy fotografieren, Bild zum Server, Server zählt und ordnet Steine, Alles in DB vom Webshop speichern, auf der Shop-Webseite verkaufen - jetzt das Ganze mit JavaFX? Mit meinem Roboter zum Sortieren bin ich leider an der Hardware gescheitert. Da ich leider keine Lust habe, das per Hand zu machen, wird das wohl nie online gehen und somit ein Prototyp bleiben.
Natürlich wird man immer Ausnahmen oder Nischen finden. Wenn man die bedienen möchte ist das auch völlig in Ordnung. Spezialisten sind in Nischen gefragt und können da zeitweise gut verdienen. Aber Zeit- und Kostendruck werden immer schnelle und flexible Lösungen verlangen. Es ist nun mal viel schneller eine Webseite auf einem Mobilgerät zu öffnen, als eine JavaFX-Anwendung auf ein Mobilgerät zu portieren - mit ungewissen Ausgang und dem Problem, wie man seine Daten aufbewahrt und weitergibt.