Zukunft: Java für Desktop-Apps?

tuxedo · 8. November 2018 um 15:41

Hey Leute,

ich habe die vergangenen 2 Jahre eine kleine aber feine Desktop-Anwendung basierend auf Swing und dem Nimbus LaF auf die Beine gestellt. Alles funktioniert soweit. Als “Schnittstellen” braucht muss die Anwendung von Anwender mit XML-Dateien sowie Daten über Eingabe-Felder gefüttert werden, auf der anderen Seite werden die Daten über Netzwerk und/oder serielle Schnittstelle weiter kommuniziert.

Aber ich habe mehr und mehr das Gefühl dass was das UI betrifft ich “mit der Zeit” gehen müsste.
Bin dann schnell auf JavaFX gestoßen. Das hat schon was: Schickes Konzept, schicke UIs. Aber hat das Zukunft? Wenn man den News folgt, dann gliedert Oracle JavaFX ja gerade aus dem JDK aus. JavaFX wird also an die Community übergeben. Aktuell hat es für mich noch den Eindruck dass es ein wenig “gefrickel” ist. Der Scene-Editor hat so seine Macken. Es funktioniert alles irgendwie, aber es wirkt nicht besonders “rund”.

Swing ist auch irgendwie totgesagt. Ja, es steckt noch im JDK, aber die Anwendungen sehen trotz den vielfältigen LaFs doch irgendwie “altbacken” aus.

Zuguter letzt steht das Thema “überall laufen lassen” immer mehr im Vordergrund. Die Leute nutzen mehr und mehr Tablets und mobile Geräte. Eine Java-Desktop-Anwendung und eine Android mobile Anwendung separat entwickeln klingt nach zu viel Aufwand.

Es gibt mehr und mehr Lösungen die Anwendung auf HTML/Web-Techniken basieren zu lassen und Java mehr in den Hintergrund zu rücken, also als Backend/Logik-Seite laufen zu lassen.
Aber mir rollen sich die Nägel hoch wenn ich an die ganzen Krücken und Stolpersteine denke die dafür notwendig sind die resultierende Anwendung wahlweise als Desktop-Anwendung und als Server/Web-Anwendung zu realisieren.

Meine Anwendung ist mehr oder wneiger schon so aufgebaut dass ich UI von Logik trennen kann: Zwei Projekte. Eins die ganze Business-Logik und so weiter, eines das mehr oder weniger reine UI.

Die aktuellste Idee die mir vorschwebt:

Meine Logik mit einer REST-Schnittstelle “webfähig” machen und darauf ein leichtgewichtiges WEB-UI setzen.
Für “lokale Desktop-Anwendung” müsste dann halt ein lokaler Jetty oder sowas her und die Anwendung läuft dann auf localhost im Browser, oder wird irgendwie so in einer Wrapper-Anwendung gekapselt, dass es aussieht als wäre es doch eine Desktop-Anwendung.
Und für die Server-Lösung: Die Logik mit REST auf den Server klatschen und dann halt entfernt mit dem Browser drauf zugreifen.

Aktuell würde ich sagen ich brauche noch beide Lösungen. Weil eben die Anwendung beim User laufen muss. Ich kann das technisch nicht als Web-Lösung von mir gehostet anbieten (serielle Schnittstelle und so). Aber in einer “Experten-Variante” könnte die Server-Seite auf einem kleinen Server laufen. Und das wird auch irgendwann sicherlich soweit kommen. Aber bis dato brauch ich noch die Desktop-Only-Variante.

Was ist denn euer Favorit wenn es um UI Entwicklung innerhalb der Java-Welt geht? Tatsächlich noch JavaFX oder Swing?
Oder gibt es doch schicke und einfache Wege das UI mit Web-Techniken zu lösen und an Java anzubinden?
Wie sind da eure Erfahrungen?

Gruß
Alex

L-ectron-X · 8. November 2018 um 16:42

Ich schreibe derzeit meine UIs mit Swing, denen ich das System-LAF setze. Einige fehlende UI-Komponenten, die man in anderen Desktop-Betriebssystemen findet, kann man mit dem nicht mehr weiterentwickelten SwingX integrieren.

Aber du hast hast Recht, das Ganze ich vielleicht nicht mehr zeitgemäß. JavaFX werde ich mir daher auch einmal näher ansehen.

Abgesehen davon glaube ich an eine Zukunft mit Web-Applikationen.

Tomate_Salat · 8. November 2018 um 17:14

In kleineren Prototyp-Projekten hab ich dafür einfach immer gern eine Spring Boot Anwendung gebastelt.

Im wesentlichen sah das dann gegen Ende so aus:

Backend: Sprint Boot
Frontend: React

Hinzu kamen dann noch 2-3 Powershell-Scripte welche im wesentlichen folgendes gemacht haben:

Baue die React-Anwendung
Kopiere die Anwendung in den static-Folder der Spring boot Anwendung
Baue und packe die Spring Boot Anwendung

Heraus kam dann eben eine JAR die ich einfach verteilen hätte können und zugleich noch die eigene UI hostet. Fand das eigentlich ganz cool.

Aber die Einarbeitungszeit war nicht gerade ohne.

TMII · 8. November 2018 um 17:59

FXML ist ähnlich wie eine Webseite von der Platform Unabhängig, solange es einen Interpreter gibt.
Java hat mit JavaFX zwar eine direkte Anbindung, ist aber nicht Java exklusiv. Man kann auch JavaFX Anwendungen für Android schreiben und es gibt Dienste die FXML in Browser anzeigen können.

Marco13 · 8. November 2018 um 18:04

Ja, ich habe auch manchmal sehr dystropische Visionen.

Das wichtigste Heilsversprechen von Web-basierten Anwendungen ist, dass man das UI einmal schreibt, und überall laufen lassen kann. „Write once, run anywhere“. Was für eine tolle, innovative Idee. Was schief gelaufen ist, und bewirkt hat, dass der Browser jetzt „die“ Virtuelle Maschine ist (die „nativ“ mit JavaScript läuft ) könnte ich nichtmal genau sagen. Aber ich kann nicht im geringsten nachvollziehen, wie jemand, der sich (auch oder gerade?) mal oberflächlich mit Web-Entwicklung beschäftigt hat, meinen kann, dass das, was da läuft, „sinnvoll“ ist. Als Grundlage eine ungetypte Sprache in der man fast zwangsläufig unwartbaren Code schreibt, ohne irgendein Modul- oder Deployment-Konzept, wo man mit irgendwelchen Babel/TypeScript/Whatever-Transpilern versucht, etwas drüberzustülpen, was handhabbar ist, und wo man dann nacheinander mit Angular, Angular2, Angular4, Vue, React, Knockout, Ember oder einem anderen aus der Liste von Webframeworks – Wikipedia ein und dieselbe Anwendung erstellt, die wegen Inkompatibilitäten zwischen Versionen und verwendeten Bibliotheken jedes mal from scratch neu gebaut werden muss, und wo man sich jedes Mal über Dinge ärgert, wie dass der linke Rand einer Tabellenzelle vom Bootstrap-Layout im Internet Eplorer 10 unter Windows Montags und Mittwochs 3 Pixel breiter ist, als er sein sollte.

Swing funktioniert.

^{OK, ich maße mir gar nicht an, da objektiv zu sein.}

Ich denke, ein wichtiger Dämpfer Für JavaFX war das, was als " nicht besonders geradlinig" bei JavaFX – Wikipedia beschrieben ist. Sie hatten erst den falschen Ansatz. Wenn sie da besser gezielt hätten, würden gäbe es Angular oder React vielleicht gar nicht. Wer weiß.

Was die Zukunft bringt? Nun, ich entwickle weiterhin privat viel mit Swing. Natürlich. Für den Desktop gibt es nichts besseres. Aber ich gehe auch davon aus, dass die nächste (d.h. aktuelle) Generation von Entwicklern (und Entscheidern) „Java auf dem Desktop“ als Auslaufmodell sieht. Mit Swing sowieso, und ob JavaFX da noch etwas rausreißen kann, wir sich zeigen

_{Vielleicht gibt’s dann aber auch Firmen, die Leute brauchen, die ihre internen, proprietären, komplexen, über Jahre gewachsenen und nicht sinnvoll ins Web übertragbaren Swing-Anwendungen weiterpflegen. Meldet euch dann bei mir. Wird aber nicht billig}

tuxedo · 8. November 2018 um 20:11

Ich bin eigentlich auch kein Freund zu dem ganzen Web-Hype. Aber Swing ist nicht mehr der Knüller. Ja, es läuft, und ja man kann sich auch selbst komplexe Controls basteln (hab ich auch schon gemacht), aber irgendwie ist es nicht mehr zeitgemäß.

FXML … hab da schon reingeschnuppert, aber da stoße ich schnell an die Grenzen hab ich das Gefühl. Vor allem wenn es um eigene Controls geht. Zumindest mit dem Editor.
An JacaFX stört mich eigentlich nur, dass es irgendwie keine allzu lebendige Community dahinter gibt. Sonst gefällt mir das Konzept sehr gut.

FXML im Web: Ja, da steht im Werbeflyer. Aber das wurde - soweit ich das überblicken konnte - mit Applets gelöst. Und die sind ja nun tot. Java im Browser existiert nicht mehr.

JavaFX auf dem Handy: Ich hab da was von einem Tool gelesen mit dem das gehen soll. Hab das auch ausprobiert. Aber bereits die Demo-Anwendung hat ausgesehen

a) wie ein Proof-of-Concept
b) wie eine Java-Desktop-Anwendung per Screen-Scraping aufs Handy gebracht: Auflösung hat vorne und hinten nicht gestimmt, Bedienung mit dem Finger unmöglich.

Die Anwendung die ich da habe soll möglichst lange laufen und „self-contained“ sein. Ist eine Software zum parametrisieren von Geräten in der KNX Hausautomatisierung. Das heißt die Anwendung sollte in 10 Jahren noch so laufen wie heute. Zur Not packt man alles in eine VM.
Bei einer Browser-Anwendung … ich weiß nicht wie das in 10 Jahren da abläuft. Da hat sich ja verdammt viel getan in den letzten 10-15 Jahren. Aber der Trend geht nunmal in die Richtung. Wird nicht einfach da gegen den Strom zu schwimmen.
Bei meinem RestAPI/Web Ansatz hätte ich auch versucht mich auf das notwendigste zu beschränken und mich nicht dem ganzen modernen JS/TS/wasweißich-Framework hinzugeben. Möglichst viel reines HTML, schick gemacht mit CSS (was auch schon Probleme mit sich bringt). Na mal sehen …

Was ich also bei euren Kommentaren so im Schnitt raushöre: Eher JavaFX als Web.

Hab auch schon nach alternativen Toolkits gegoogelt. Apache Pivot… Klang erstmal vielversprechend. Letztes Release war aber auch vor 4 Jahren. Also auch tot.
Finde es traurig dass Java auf dem Desktop mehr und mehr stirbt.
Das ganze JS/TS/NodeJS Geraffel… Ich hab das täglich im Büro. Es „geht irgendwie“, aber ich tue mich da nach 15 Jahren Java verdammt schwer. Da gibt’s so viele Dinge die in Java so schön gelöst sind, die man dann in TypeScript mit noch mehr unverständlichem Code umschiffen muss. Ich weiß auch nicht. Ich hab vorne noch keine 4 dran stehen, aber ich glaube ich bin zu alt für den sch**ß

Gruß
Alex

Landei · 8. November 2018 um 20:55

Vielleicht wäre Vaadin für dich eine Alternative, und es ist konzeptionell gar nicht so weit von Swing entfernt.

tuxedo · 9. November 2018 um 07:38

Vaadin ist in der Tat schon in der engeren Auswahl. Aber Vaadin als “lokale” Anwendung gekapsel laufen lassen scheint nicht so einfach zu sein wie man sich das vorstellt:

Vielleicht ist es dann doch einfacher per Script/Batch einen Jetty zu starten und den Browser mit der passenden URL zu öffnen…

Muss mir das noch genauer anschauen.

Landei · 9. November 2018 um 08:01

Der große Vorteil ist, dass du alles in einer Anwendung, mit einer Sprache hast, auch wenn die serverseitig läuft.

Vaadin hat (oder hatte zumindest das letzte mal, wo ich es mir angeschaut habe) einige Beschränkungen was die URLs angeht (ist eben als Single-Page-Anwendung gedacht und erlaubt keine bookmarkfähigen URLs out-of-the-box). Weiterhin schlagen einige Einschränkungen von GWT durch: Bestimmte Klassen sind remote nicht verfügbar, und es müssen Java-Source (also z.B. kein Kotlin) sein.

Übrigens: Kotlin selbst kann zu JS kompiliert werden, theoretisch ginge das auch als “Web-Framework” durch: https://medium.com/bcgdv-engineering/building-a-full-stack-web-app-in-kotlin-af8e8fe1f5dc

Ich hoffe, dass Webassembly endlich aus dem Knick kommt, damit man endlich sein Frontend entwickeln kann, womit man will…

tuxedo · 9. November 2018 um 08:16

Der Vaadin Vorteil ist bekannt, deshalb ist es bei mir ja auch in der engen Auswahl. Alles mit Java freu

Das mit SinglePage und dem Bookmarkproblem… okay, ist jetzt neu für mich, aber kein wirkliches Problem. ich will ja eine “Anwendung” und keine Webseite die man abschnittsweise bookmarken kann.

Ich hab die Tage erst einen Artikel zu WASM gelesen. Quintessenz: javaScript und Co wird uns erhalten bleiben, auch für das Frontend. Vielerlei Frameworks werden allerdings den Schritt zu WASM gehen (im Hintergrund, während im Vordergrund immer noch JS aktiv ist) und eine Menge “Spezialdinge” kann man dann performant mit WASM machen. Aber ich denke nicht, dass WASM eine gewaltige Änderung bringen wird was UI/Frontend Entwicklung angeht.

Ich frage mich seit Jahren warum man keine JVM in den Browser fest einbaut. WASM ist ja quasi nix anderes, nur dass es jetzt erst entwickelt werden muss und man das Rad nochmal neu erfindet, mit allen Höhen und Tiefen.

eagleeye · 9. November 2018 um 11:00

ich weiß nicht, ich denke die Frage „Was ist die Zukunft“ ist verdammt schwer zu sagen
ich denke dass uns der ganze JS Müll lange verfolgen wird, weil da JS jetzt überall ist werden uns die Webfrickler überall verfolgen.

Ja man kann mit den ganzen JS Frameworks super Webseiten bauen (ich hab paar Projekte mit Polymer gemacht) was echt gut geht. Aber die größten Bauchschmerzen die ich aktuell hab, ist einfach die Schnelllebigkeit. Alle paar Monate kommen neue Frameworks raus und genauso schnell verschwinden sie wieder, leider laufen da alle große Firmen gleich. Teilweise weil sie ihren Teams „zu viel Freiraum“ lassen, z.B. MS kauft vor Jahren Xamarin benutzt es auch teilweise, baut nach aktuellen Infos aber die Skype App mit React Native …

Ich würde sagen die Frage was man nutzt hängt primär davon ab was man erreichen will und in welcher Umgebung man sich bewegt. Ist die Anwendung eigentlich nur ein (einfaches) Frontend zu nem Backend, dann macht ne Webseite definitiv Sinn. Ist das Backend nur nen kleines Anhängsel, scheiß auf Web da kotzt man nur unnötig

Weil auch diese Aussagen die es seit Jahrzehnten gibt „Write one run everywhere“ sind naja. Schreibe ich eine App für Android werde ich sie nicht 1:1 auf nen iPhone bringen sollen, weil iOS User andere Benutzung gewöhnt sind. Klar man kann es machen, ist aber scheiße
Das gleiche mit Desktop, Tablets & Co

eagleeye · 9. November 2018 um 11:01

Wieso, wenn die Seite gut gebaut ist kannst du sie auch Bookmarken

eagleeye · 9. November 2018 um 11:03

guck dir mal electron an, das is eine Chrome Umgebung in der du deine Sachen laufen lassen kannst, so macht es Slack und viele andere “Programme” ich kann dir aber nicht sagen wie das genau abläuft

tuxedo · 9. November 2018 um 11:06

Electron kenne ich. Ist auch das was Vaadin für di3 “Desktop Variante” so angibt. Die Anleitung ist aber Gefühl ewig lang mit vielen Hürden.

eagleeye · 9. November 2018 um 11:24

ja das glaube ich, deshalb würde ich auch wenn ich zu 90% kein Web brauche auch keine Webanwendungen bauen.
Will ich nur aufm Win Desktop sein, würde ich einfach eine UWP App bauen, die Plattform ist super, die Tools sind wie üblich von MS verdammt gut.
Wenn du es auch aufm Mac haben willst kannst du dann problemlos Xamarin nutzen oder du fängst direkt mit Xamarin Forms an.
Gleiches Spiel mit Mobile.

Wobei ich sagen muss das ich teilweise lieber 2x die UI Arbeit mache aber dafür ne gescheite Oberfläche habe, als dass ich komische Websachen baue. Gerade mit komplexeren UIs macht das wenig Spaß finde ich.

tuxedo · 9. November 2018 um 13:43

Meine Zielgruppe nutzt Windows, Linux und Mac.

Da die Anwendung recht technisch angehaucht ist (KNX Heim-Automatisierung), steht auch die Überlegung im Raum einen kleinen Hutschienen-Server in den Verteiler zu den ganzen KNX Geräten zu hängen (Netzwerk ist da immer mehr verfügbar), und da die Anwendung als Web-Anwendung drauf laufen zu lassen. Das würde gleich noch ein paar Hardware-Stolperstellen beim User glattbügeln. So hätte man die Hardware (Netzwerk/Seriell) unter Kontrolle und das Endgerät wäre beliebig. Software-Installationsaufwand = 0.
Aufwendige Controls hat die Anwendung eigentlich nicht, nur ein paar Eigenheiten die aber nicht wirklich der Rede wert sind.
Deshalb also die Idee das auf WEB umzubauen. Nur eben mit der Option es dann doch local-only auf Mac, Windows oder Linux laufen zu lassen.
Aber bis es mit der Hardware auf der Hutschiene soweit ist, sollte es halt noch lokal laufen.

Werde mir wohl (auch für ein anderes Projekt) Vaadin und ggf. Electron genauer ansehen müssen.

eagleeye · 9. November 2018 um 13:54

ja auch wenn ich es nicht mag, das klingt sehr für einen Web Kandidaten
was ich mal mit in den Raum werfen würde wäre Polymer, damit setze ich aktuell alle mein Webprojekte um (wenn ich die Wahl habe)

Marco13 · 9. November 2018 um 17:41

Da ich mich mit bestimmten technischen Dingen da nicht so auskenne, lehne ich mich da jetzt mal deutlich weiter aus dem Fenster, als sonst. Aber ich glaube, dass ein Punkt, der den Webanwendungen wie ein Klotz am Bein hängt, der ist, der so “selbstverständlich” erscheint, dass, wenn ich das jetzt erwähne, einige vielleicht denken (und wenn, dann auch hoffentlich sagen) werden: “Häh, was labert der Spinner denn da, wie soll das denn sonst alles funktionieren?”.

Der Punkt ist: Der Browser braucht HTML und CSS. Das ist schlicht nichts, was für Anwendungen gemacht ist.

Schon ein simpler Button (also ein rechteckier Bereich, wo man draufklickt) ist dadurch so haarsträubend kompliziert, dass eben ein dutzend Abstraktions- und Helferschichten drumgewickelt werden müssen. Es gibt im Browser schlicht keine “GUI-API” (bzw. jedes Webframework definiert seine eigene). Dass dort in bezug auf Layout etc. einige Fragen noch dringender und schweieriger werden, als auf dem Desktop, ist klar. Aber solange ich nicht (ohne Angular, CSS, Babel, Typescript-Transpiler, Dust und einigen hundert Hilfsbibliotheken, die den Development-Ordner rubbeldiekatz mal auf >10000 Dateien und >1GB anschwellen lassen) sowas schreiben kann wie

myWebsite {
    setColumnLayout(leftPanel, rightPanel)
}
leftPanel {
    add(someButton)
}
rightPanel {
    add(someTextField)
}
someButton {
    text: "Press me!";
    action: someFunction();
}
someTextField {
    font: "Comic Sans"
}
void someFunction() {
    Text response = callGET("example.com");
    someTextField.text = response;
}

weiß ich nicht, wie solche Entwicklungen mit einem vernünftigen Aufwand-Nutzen-Verhältnis betreiben soll. Selbst wenn man (weil ein Manager unüberlegt eine Entscheidung getroffen und einen dicken Scheck unterschrieben hat) mit viel Aufwand so eine Anwendung erstellt, sehe ich nicht den geringsten Hauch einer Chance, da etwas nachhaltiges zu schaffen. Der Wartungsaufwand ist aus den oben schon an verschiedenen Stellen angesprochenen Gründen astronomisch.

EDIT: Kleiner Outtake, fand’ das nur gerade lustig:

(Es geht da um eine Website. Mit Text drauf. Keine Anwendung.)

eagleeye · 10. November 2018 um 15:06

ja Marco, wobei ich sagen muss das hängt massiv von Framework ab.
Ich war mal in einem Projekt am Rand beteiligt wo Angular benutzt wurde und das wirkte auf mich extrem scheiße, aber auch nen Kollege der mal rein gesehen hatte hatte nur gekotzt weil die Entwickler scheiße waren,

Wie gesagt ich mach einige Dinge mit Polymer und das geht echt gut, aber damit würde ich auch keine wirkliche größere Anwendung schreiben wollen

Marco13 · 10. November 2018 um 21:53

Gerade die passende Frage:

(Hab für “Close as primarily opinion based” gevotet, aber einen Kommentar dagelassen…)