Zukunft: Java für Desktop-Apps?


#21

Hab heute zum ersten mal Java 11 ausprobiert in dem JavaFX nicht mehr enthalten ist.
Ich empfand den Aufwand JavaFX zum laufen zu bekommen für Java Verhältnisse hoch. Leider ist das ganze auch nicht mehr Plattformunabhängig, aber das ist Java bereits seit Java 9 nicht mehr.
Es ist klar dass sich Oracle mit Java aus dem Front-End komplett zurückziehen möchte.

Zumindest für den Moment muss ich meine JavaFX Empfehlung doch nochmal in Frage stellen, oder Java allgemein…


#22

Was hast du denn gemacht, dass du den Aufwand als hoch empfunden hast?
Ist schon etwas her, dass ich das probiert habe, aber mehr als Dependency einbinden hab ich da nicht in Erinnerung (zumindest wenn man es ohne Module macht.)

Warum sollte Java nicht mehr Pattformunabhängig sein?


#23

Dazu müsste ich in mehrere Richtungen schießen, inklusive IntelliJs mangelnden Support für Module. Ist leider alles kein Plug n Play mehr.
Dadurch dass es keine JRE mehr gibt und man sich diese nun selber zusammen basteln muss, kann man wirklich nicht mehr von Plattformunabhängigkeit sprechen wenn man jetzt gegen jedes Betriebssystem einzeln compilen muss und für jedes Betriebssystem ein eigenes Paket bekommt.

Das fällt besonders auf weil weder das JDK noch das JFX-JDK Plattformunabhängig sind. Auf Windows bekommt man ein Windows Image und auf Linux ein Linux Image.

“Platformunabhängigkeit” war schon immer ein kontroverses philosophisches Thema, aber so ist das relativ eindeutig und kaum anders als mit Sprachen wie C++. Nicht falsch verstehen, es bringt natürlich auch Vorteile eine eigenständige Runtime ausliefern zu können.

JavaFX unter IntelliJ einzubinden stellte sich bereits als Problematisch heraus, weil mein Maven anscheinend nicht verstanden hat dass es die Windows Dateien herunterladen soll (Platformunabhängig und so). Manuell herunterladen und einbinden ist dann eine Sache, eine kompilierte Stand-Alone Version in IntelliJ heraus zu quetschen, eine komplett Andere.
Aber das war schon immer ein Problem von IntelliJ, der Build-Prozess.


#24

Natürlich gibts noch JRE’s: https://github.com/AdoptOpenJDK/openjdk11-binaries/releases
Nur nicht mehr von Oracle, aber wer will das seit noch 11 nutzen (außer man hat viel Geld und braucht Support)?

JavaFX war btw nie wirklich Plattformunabhängig. Das war immer nur Teil des Oracle-JDKs, bei allen anderen musste man hoffen, dass die Nutzer das in der passenden Version nachinstalliert hatten, zumindest das entfällt jetzt…

Zur Not hart angeben, bisher kenn ich da keine Probleme, dass kann durchaus ein Bug in Maven sein


#25

Da hast du wohl Recht, das hatte ich in dem Moment nicht mehr bedacht. Zum Glück brauchen die Linux Server keine Oberfläche :sweat_smile:
Das hat sich mit dem OpenJFX zumindest geändert.
Dennoch steht die Aussage schöner wäre wenn man mit dem JDK und JKD-JFX die Binaries direkt für alle Platformen bekommt.

Das JDK ist nicht das JRE. Ich kann nicht von meinen Kunden verlangen sich das JDK herunterzuladen und manuell wie eine globale JRE einzurichten. (Klar enthält das JDK eine JRE).

Die Titelfrage war ob Java auf dem Desktop Zukunft hat. Im Moment ist der gesammte Java 11 Buildprozess in der Art buggy und die Tools in der Art unausgereift - und wir sprechen hier vom aktuellen Build - dass es im Moment eher nicht danach aussieht.
Wenn das ganze auf einen verwendbaren Kurs zurück kommt, hab ich auch keine Bedenken mehr.

Ich hab auch keine Bedenken dass hier im Thema jemand nicht in der Lage wäre damit trotzdem zu arbeiten. Und wenn man einfach auf eine ältere Java Variante zurückgreift.
Es ging/geht mir im Moment einfach um den derzeitigen Zustand.


#26

@TMII
Kann dir da nur voll und ganz zustimmen. Java ist gerade im Wandel. Aber mir persönlich kommt das nicht “lange geplant und gut ausgeführt” vor, sondern eher “über’s Knie gebrochen”.

Lange Zeit wurde von ein paar Seiten auf Java eingehackt “Java entwickelt sich nicht weiter”. Dem kann ich zustimmen. Java war viele Jahre für meine Verhältnisse “konstant gut bis sehr gut”.
Auf einmal scheint man auf die Hipster-Kritiker zu hören. Ergebnis: Ein Umbau der - wie ich finde - seines gleichen sucht.
Vielleicht hätte man dem “Kind” einen neuen Namen geben sollen. Dann wäre klar gewesen: Hier tut sich enorm viel.
Bin die letzten Wochen und Monate mehrfach den Neuerungen in Java hinterher gerannt. Zum einem die neuen Versionen. Ich meine ich hab in den zwei Jahren die mein kleines Projekt läuft nun 3 oder 4 Java Versionssprünge drin. Okay, ich war zu beginn nicht ganz aktuell, aber gut.
Zum anderen hab ich seit Java 9 immer wieder Probleme mit JAXB. Und jetzt war ich vergangene Woche auf der Suche nach dem JRE und hab nur das JDK gefunden.
Mir kommt es an der Stelle tatsächlich so vor, als wolle man seitens Oracle komplett weg vom Desktop, hin zum reinen Backend. Vielleicht sieht man hier auch schon seine Felle davonschwimmen. Immer mehr wird ja mit diesem Monster “NodeJS” gemacht. Begünrdung die ich oft höre: Schneller und Ressourcensparender.

Ich fände es schade, wenn die Entwicklung so weiter geht, die Sprache wechseln zu müssen. Java bietet verdammt viel, ist einfach und leistet enormes. Auf JS/TS/… als neue “Stammsprache” hab ich weder Lust noch Nerven.
Ein Kollege in der Firma bastelt gerne mit Groovy. Ergebnis: Ja, der Code ist kurz bzw. kürzer. Aber ich hab als Java Entwickler dadurch nix gewonnen. Bis ich mich auf Groovy eingestimmt habe, habe ich das Problem auch in Java gelöst. Und nur wechseln damit ich wechsel damit ich wieder “hip” bin… Nein danke.
Für mich haben alle anderen Sprachen keine Probleme gelöst die sich nicht auch adäquat mit Java lösen lassen (außer vllt. das JSON handling… das ist in JS halt deutlich einfacher/besser als mit Java).

Aber gut. Zurück zum UI/Desktop Thema:

Ich hab gesehen dass Gluon den JavaFX Scene Builder in einer recht neuen Auflage hat. D.h. da hat sich die letzten 6 Monate tatsächlich was getan. Ich werde der Sache auch nochmal eine Chance geben bevor ich auf Vaadin oder ähnliches setze.

Was die ganze Build-Geschichte mit Java 11 betrifft und dem fehlenden JRE: Vielleicht muss man sich hier nur erstmal einarbeiten, und vielleicht wird die Sache hier auch noch deutlich besser. Mal sehen.

Gruß und schönes Rest-Wochenende,
Alex


#27

Da gibt es das JDK UND das JRE.

  • OpenJDK11-jdk_x64_windows_hotspot_2018-10-31-06-32.zip 184 MB
  • OpenJDK11-jdk_x64_windows_openj9_2018-10-31-06-32.zip 188 MB
  • OpenJDK11-jre_x64_windows_hotspot_2018-10-31-06-32.zip 36.7 MB
  • OpenJDK11-jre_x64_windows_openj9_2018-10-31-06-32.zip 38.2 MB

Bisher nur dort, soll bald aber auch auf deren Website zu finden sein, inklusive Installer und allem drum und dran.

Bei beiden ist die Installation doch auch genau gleich? Zumindest kann mich nicht erinnern, dass ich irgendwann mal ein JRE anders installiert habe, als ein JDK.

Für jlink und Multi-Release-Jars ist die Tool-Unterstützung noch nicht wirklich gut bzw überhaupt vorhanden, das könnte wirklich besser sein. Aber es ist ja in Arbeit.

Ganz normale Builds laufen aber mit 11 nicht wirklich anders. Auch mit JavaFX klappt das ziemlich problemlos, bis auf die drei Versionen, die man jetzt bauen muss.

Einfach die Dependancie einbinden sollte eigentlich immer Problemlos klappen, was gab’s denn da für Probleme?

Siehe den Link oben, von AdoptOpenJDK gibts auch das JRE in zig Varianten.

Wenn einen das neue Zeug nicht interessiert kann man in den meisten Fällen den Build so lassen, wie er unter 8 war (abgesehen von aktualisierten Dependencies.)


#28

Zum Thema JDK/JRE:

Ich bundle meine Anwendung sowieso mit der JVM, von daher hat auch kein User damit irgend einen Stress. Hab aktuell eben das OpenJDK mit eingepackt, vorher das Oracle JRE. Für den User ergibt sich nur ein Unterschied: Die Anwendung ist durch das JDK nun etwas größer. Aber Speicherplatz kostet ja nix mehr. Von daher. Who cares?!

Zu den Problemen die ich seit der modularisierung von Java habe:
JAXB nutzt wohl Klassen auf dem JDK/JRE die jetzt nicht mehr per default inkludiert werden. D.h. einfach die Java Version wechseln ist nicht mehr, ich müsste nun mein Build so umbauen, dass dieses “nicht mehr default modul” mit eingepackt wird. Und dieser “Modul-Build” ist ne andere Sache als in Maven einfach ne Dependency hinzuzufügen oder zu ändern.
Da mir das aber zu blöd war, bin ich auf die Suche gegangen und hab ne JAXB Alternativimplementierung gefunden die das mit eigenen Klassen löst. Also kurz die Maven Dependency geändert und schon läuft es wieder.
Daneben gab/gibt es wohl noch Probleme innerhalb der JAXB Implementierung und der Anpassung an die Änderungen die mit Java nun mitkommen. Im Detail müsste ich das auch nochmal raussuchen. Aber kannst ja mal selbst nach JAXB und Java 9, 9, 10 oder 11 suchen.


#29

Wie gesagt: du kannst immer noch das JRE nehmen…

Natürlich muss man für Modularisierung mehr machen, als eine Dependency einbinden, das sind ja auch zwei völlig unterschiedliche Dinge - hat ja auch niemand behauptet, dass es so wäre?
Bei JAXB kann man die Modularisierung getrost ignorieren, wenn man sie nicht möchte.

Hier steht was man machen muss und wo man was findet: http://openjdk.java.net/jeps/320#Java-EE-modules
Für JAXB ist das, die passende Dependency einbinden. Wenn das bei dir Fehler warf, klingt das nach einem Bug - was fehlte denn?


#30

Ich find das mit den Modulen einfach nur kacke. Man merkt richtig, dass sich gewehrt wurde mit den OSGi-Jungs zusammen zu arbeiten.

Vor einiger Zeit hab ich damit mal ein POC umsetzen wollen und es war einfach nicht möglich. Jigsaw + Maven ist einfach eine Qual. Afaik hab ich damals tests nicht zum laufen gebracht. Das man beim designen von dem Rotz Maven einfach anscheinend so komplett keine Beachtung geschenkt hat ist einfach nur Dumm gewesen.


#31

FullACK

Das war mein erster Gedanke: Warum musste man das Rad neu erfinden?

Ich hoffe dass entweder

a) ich keine weiteren Projekte bekomme wie ich Modulabhängigkeiten habe die durch den Default-Fall nicht abgedeckt sind
oder
b) die Integration mit Maven besser wird. Weil aktuell integriert sich das nicht sooo toll wie man das aus der Maven-Welt gewohnt ist.


#32

Naja, sein wir ehrlich: schlechter kann der scheiß nicht mehr werden :smiley:. Also Luft nach oben ist da und viel. Wenn jetzt die zuständigen Entwickler mal kurz googeln was Maven ist, dann ein oder zwei YouTube-Videos sich dazu anschauen - dann haben wir vielleicht eine Chance.

Aber ich halte es wie JavaFx für eine Totgeburt. Was ich sehr schade finde - weil ich in beiden Projekten viel potential gesehen hab und deswegen mehr als enttäuscht von Oracle bin.


#33

@mrBrown
Bzgl. JAXB… ist Monate her. An alle Details erinnere ich mich nicht mehr. Aber eben kam eine Benachrichtigung von Github zu dem Thema rein:

@Tomate_Salat
Ich hoffe nicht dass durch Jigsaw und Co. ganz Java mit in den Tod gerissen wird. Das wäre dann doch zu schade. Viel mehr hoffe ich dass die Community um OpenJDK das irgendwie auffängt.

Und JavaFX … mal schauen was das nächste halbe Jahr bringt und wie sich die Community entwickelt. Viel früher komme ich eh nicht dazu mein UI (komplett) zu überarbeiten.


#34

Glaube ich nicht. Denke dass es dann eher in die Richtung geht, dass außer Oracle es keiner verwenden wird/kann. Solange uns der Classpath erhalten bleibt sehe ich keinen Grund zur Besorgnis.

Sollte er doch weg fallen, dann hoffe ich, dass die Community entsprechende Tools bis dato entwickelt hat um das zu kompensieren (zur Not: Fatjar). Und dann will Oracle ja Geld mit Java machen - das werden die wohl kaum, wenn Sie alle Maven-basierten-Projekte einfach mal so unbrauchbar machen.


#35

Na der CP wird nicht gleich wegfallen. Aber wenn keiner die Module nutzen will, müssen einige Projekte die nicht alleine aus dem Default-Modul bedient werden können, erst angepasst/umgebaut werden damit sie mit den neuen Versionen von Java wieder laufen.

An sich finde ich es toll dass man sich nun eine angepasste JRE selbst zusammenbauen kann. Das ermöglicht nun auch mehr und besser “Microservices” ohne viel Overhead der JVM.
ein HelloWorld in Java mit eigener Micro-JRE und ein HelloWorld in NodeJS sind so näher beieinander als je zuvor. Zumindest was die finale Projektgröße anbelangt.
Gerade im Cloud Umfeld wo alles nach Docker und Microservices schreit, gehen viele mehr und mehr den sparsamen Weg.
Aber der bisherige Default wäre doch ganz hilfreich gewesen. Hätte niemandem weh getan wenn die Default-JRE mit ihren Modulen dem bisherigen Default entsprochen hätte.


#36

Das ist allerdings das jaxb2-maven-plugin, JAXB ist erstmal völlig unabhängig davon.


#37

Mag sein, aber ich komme da nur schwer drum rum wenn ich aus XML Code generieren muss während des Build-Prozesses.


#38

Auf dem Weg mit das OpenJDK 11 für Windows runterzuladen bin ich über die OpenJDK Seite auf das hier gestolpert:

https://openjfx.io/

Schon interessant dass die Seite zwar in einem recht aktuellen Stil und auch erstmal informativ gestaltet ist, man sie aber doch irgendwie erst recht spät (zumindest bei mir) darüber stolpert.


#39

Interessant. Sowas wie https://github.com/FXyz/FXyz sieht schon nach fancy shit aus, und die anderen Besipielprojekte scheinen auch einen weiteren Blick wert zu sein. Ein bißchen Hoffnung besteht ja noch: Auch wenn JavaFX im Moment etwas stiefmütterlich behandelt ist, könnte die Absehbarkeit des Endes von Swing (zusammen mit der tief sitzenden Verachtung, die einige für ““Webframeworks”” haben) und solche Projekte den nötigen Momentum generieren. (Ich fand ja schön, dass sie sowas wie https://docs.oracle.com/javafx/2/charts/chart-overview.htm#CJAHHJCB direkter anbieten. Ja, JFreeChart ist OK, aber wenn das Teil der Kern-API ist, ist das doch nochmal was anderes…)


#40

Man darf nicht vergessen, dass OpenFX 11 auch ein Monat vor Java 11 herauskam.
Die Webseite ist auf Google noch nicht direkt auffindbar. Entweder direkt über Gluon oder über die Webseite vom OpenJDK.

Hab die letzten Tage noch ein paar mal versucht das zum laufen zu bekommen und zwei Bugs im Tracker. Mal schauen ob sich da noch was macht.