# Erwaege JavaFX Einstieg



## sirbender (25. Aug 2019)

Hallo,

ich habe viel Erfahrung mit Swing. Ueber JavaFX hab ich immer nur News-Meldungen gelesen. Am liebsten wuerde ich einsteigen indem ich ein Beispiel-Projekt sehr genau unter die Lupe nehme. 

Gibt es vielleicht ein Projekt (z.B. Github) wo man z.B. durch einen guten Gradle Build sowohl fuer Desktop, Android, Browser als auch iOS die Faehigkeiten von JavaFX deutlich sehen kann?

vielen Dank,
sb


----------



## mrBrown (25. Aug 2019)

sirbender hat gesagt.:


> Gibt es vielleicht ein Projekt (z.B. Github) wo man z.B. durch einen guten Gradle Build sowohl fuer Desktop, Android, Browser als auch iOS die Faehigkeiten von JavaFX deutlich sehen kann?


Dürfte daran scheitern, dass JavaFX in erster Linie für Desktops ist, für den Einstieg dürfte das auch erstmal genug sein.

Für Web und Mobile braucht man jeweils passende Libs, zB JPro oder Gluon Mobile, wir gut die sind kann ich nicht beurteilen.


Hier finden sich einige Beispiele: https://gluonhq.com/developers/samples/, ein paar für Mobile sind auch dabei.


----------



## sirbender (25. Aug 2019)

Vielen Dank. Ich nehme an du bist nicht extrem tief in JavaFX eingestiegen bzw. nur auf dem Desktop? 

Waere toll wenn jemand der einen Gesamtueberblick hat auch nochmal zum Thema JavaFX im Browser bzw. Mobile kommentieren koennte. Ist das Weg dahin Open Source oder muss man bei Gluon und Co. einkaufen (haette ich prinzipiell jetzt nichts dagegen) bzw. macht sich abhaengig wenn deren Support mal eingestellt wird (das waere natuerlich ein Problem)?


----------



## mrBrown (25. Aug 2019)

sirbender hat gesagt.:


> Ist das Weg dahin Open Source oder muss man bei Gluon und Co. einkaufen (haette ich prinzipiell jetzt nichts dagegen) bzw. macht sich abhaengig wenn deren Support mal eingestellt wird (das waere natuerlich ein Problem)?



Gluon Mobile ist kostenlos nutzbar, allerdings gibts dann Werbung für die volle Version innerhalb der App. JPro kostet sobald man es kommerziell nutzt.



Am ehesten fällt mir zu dem Thema @dzim ein, der kann zu JavaFX immer was sagen. 

Hier war Gluon Mobile auch schon mal Thema: https://www.java-forum.org/thema/javafxports-erfahrungen.175167/#post-1107692


----------



## sirbender (26. Aug 2019)

Puhh...klingt ja nicht gerade verlockend bzgl. Gluon Mobile und JPro. Bin nicht so der Fan von Closed Source...hab mir da in der Vergangenheit mal heftig die Finger verbrannt.


----------



## sirbender (26. Aug 2019)

mrBrown hat gesagt.:


> Hier war Gluon Mobile auch schon mal Thema: https://www.java-forum.org/thema/javafxports-erfahrungen.175167/#post-1107692



Das scheint sehr hilfreich zu sein. Vielen Dank nochmal.

Vielleicht hat @dzim mittlerweile ein paar Updates zu dem Thema die er fuer erwaehnenswert haelt (ist immerhin fast 4 Jahre alt der Thread). Oder vielleicht will jemand Links zu Artikeln posten die das Thema JavaFX auf Mobile und im Browser mal ausfuehrlich im Jahre 2019 beleuchten.
Irgendwie schade, dass es da nicht mehr Aufmerksamkeit gibt, da der Standard-Weg fuer iOS und Android zu entwickeln nun auch nicht gerade super ist und keine Fallstricke hat. Eine plattformuebergreifende Methode waere echt super (CodeNameOne hat glaube ich einen Alternativansatz wobei ich mich da auch nicht so gut auskenne).

Sehr super waere ein Vorschlag fuer 2-3 kleinere bis mittlere Github Projekte die JavaFX auf Mobile beleuchten und wo man ausgiebig rumspielen kann.


----------



## mihe7 (26. Aug 2019)

sirbender hat gesagt.:


> Eine plattformuebergreifende Methode waere echt super


Das Problem ist, dass sich das Interesse der Massen in Richtung des Browsers als universelle, plattformunabhängige Anwendungsumgebung verschoben hat und das in Zukunft noch verstärkt der Fall sein wird. 

Andere Ansätze werden dadurch natürlich in den Hintergrund gedrängt, was nicht ganz unproblematisch zu sehen ist. Es wird auch in Zukunft auf das jeweilige System zugeschnittene Umgebungen brauchen, die durch den "Browser-Shift" zur Nische werden könnten.


----------



## sirbender (26. Aug 2019)

Es scheint viele Aenderungen gegeben zu haben: 
https://jaxenter.com/openjdk-mobile-project-is-back-159651.html
https://jaxenter.com/java-ios-gluon-159342.html


----------



## sirbender (26. Aug 2019)

mihe7 hat gesagt.:


> Das Problem ist, dass sich das Interesse der Massen in Richtung des Browsers als universelle, plattformunabhängige Anwendungsumgebung verschoben hat und das in Zukunft noch verstärkt der Fall sein wird.
> 
> Andere Ansätze werden dadurch natürlich in den Hintergrund gedrängt, was nicht ganz unproblematisch zu sehen ist. Es wird auch in Zukunft auf das jeweilige System zugeschnittene Umgebungen brauchen, die durch den "Browser-Shift" zur Nische werden könnten.



Du meinst der Browser wird bald 80% aller Apps abdecken und der Rest ist Nische? Und ist Java damit raus?

Irgendwie war der Trend vor wenigen Jahren ja noch umgekehrt. Wo grosse Browser-basierte Projekte eingestampft wurden weil die "letzten 10%" nicht zu erreichen waren. Ich nenne nur mal Facebook.


----------



## kneitzel (26. Aug 2019)

Also meine Sicht darauf ist sehr kritisch. Ich habe mir in der Vergangenheit diverse Möglichkeiten für eine Cross Plattform Entwicklung angesehen und die konnten mich alle nicht begeistern.

a) So toll die Idee auch klingt, dass man da in einer Sprache gleich ganz viel abdecken kann: Das wird in den Details extrem schwer. Es gibt halt unterschiedliche "typische Bedienparadigmen" zwischen Android und iOS. Desweiteren kommt sehr schnell eine höhere Komplexität hinzu, denn man will ja mehr machen als nur eine "Hello World" Applikation und dann kommen Abhängigkeiten hinzu. Oft gibt es da dann fertige Plugins - sonst muss man halt doch wieder mehr oder weniger native Dinge für iOS, Android, ... machen.
==> Hier sind im Detail immer wieder massive Probleme aufgekommen. Ich habe da aber in der Vergangenheit nur Xamarin und Cordova im Detail getestet.

b) Ich würde generell raten, immer auf etwas zu setzen, das Mainstream ist oder wo dies zu erwarten ist. Deinen ersten Link verstehe ich als ein: Heya - das tote Pferd ist doch noch nicht ganz tot. Ja super...

Das JPro ist auch - so ich die Seite auf die Schnelle richtig verstanden habe, lediglich ein "Die Applikation läuft auf Deinem System und die Anzeige ist lediglich im Browser." Das ist keine wirkliche Webentwicklung. Heute sind wir doch deutlich weiter und die Entwicklung schreitet weiter voran. Web-Applikationen, die auch offline funktionieren können und so ... Also evtl. eine Lösung, wenn man JavaFX Applikationen hat und diese irgendwie im Web anbieten will ... aber wirklich gut und durchdacht klingt das nicht, denn ich sehe da einige Dinge, die man vor einem Einsatz auf jeden Fall im Detail prüfen möchte bezüglich Security und so.

Für mich war damals dann die klare Entscheidung:
Native Entwicklung für Android und iOS. Klar: Viel Arbeit, aber man konnte Dinge aus dem Mainstream mitnehmen und es wurde so sehr viel einfacher, Informationen zu gewinnen und die Komplexität war am geringsten.

Auf Grund der Entwicklung derzeit sehe ich aber auch die Web Applikationen weiter im kommen. Und wo native Applikationen benötigt werden, könnte man dann ggf. Electron / Cordova / ... einsetzen. Electron sehe ich als sehr gut platziert im Markt an (Wird von vielen genutzt, ein prominenter Vertreter ist z.B. Microsoft mit Visual Studio Code). Cordova ist die Open Source Lösung hinter kommerziellen Angeboten wie PhoneGap (Adobe). Aber da habe ich auch schon Anbieter gesehen.
(Die sind auch sehr interessant, da diese Build Services anbieten. Also man benötigt nicht mehr auf Zwang einen Mac um iOS Applikationen zu bauen.)

Wenn man derzeit nicht auf eine aktuelle Mainstream Technologie setzen möchte, dann würde ich wenigstens auf einen großen Anbieter setzen. (Ich rate aber explizit nicht dazu! Ich habe da bei Microsoft schlechte Erfahrungen sammeln dürfen ....) So könnte z.B. Flutter von Google eine interessante Variante sein. Unterstützt auch native Dinge und so ....

Aber ich selbst habe für mich halt den Weg, dass ich Server Backends mit Java / JEE / Spring angehe und dann das Frontend mit Vaadin erstellt ist. Wo die Web Applikation nicht ausreicht, da kommen dann halt Android / iOS Applikationen ins Spiel, die dann per REST auf das Backend zugreifen.
==> Aber ich bin auch in der Anwendung stark limitiert. Es geht bei meinen Entwicklungen in erster Linie um Applikationen, die auf Daten basieren. Aber da haben wir ja auch noch nicht weiter über die Art der Applikation gesprochen. Z.B. für Spiele gibt es diverse Engines und so, die auch Multi Plattform sind... (Die sind auch sehr gut, denn da gibt es die Unterschiede in der Bedienung nicht mehr so massiv.)


----------



## mihe7 (26. Aug 2019)

sirbender hat gesagt.:


> Du meinst der Browser wird bald 80% aller Apps abdecken und der Rest ist Nische? Und ist Java damit raus?


Die erste Frage beantworte ich mal mit einem Ja, wenn wir zu allen Apps nur die zählen, die nicht sowieso schon auf dem Browser laufen. Offline Anwendungen können schon länger entwickelt werden (PWA) und in Zukunft soll das nicht mehr per offenem JavaScript ablaufen, sondern in kompilierter Form (Bytecode) als WebAssembly und damit sprachunabhängig, womit auch die zweite Frage beantwortet wäre. Hier gibt es einen Compiler für Java. Ob sich WebAssembly (oder doch etwas anderes) durchsetzen wird, ist noch offen, aber in meinen Augen ist klar, wohin die Reise geht.


----------



## mihe7 (26. Aug 2019)

kneitzel hat gesagt.:


> und dann das Frontend mit Vaadin erstellt ist.


Mit dem Framework oder nur den Komponenten?


----------



## sirbender (26. Aug 2019)

mihe7 hat gesagt.:


> Die erste Frage beantworte ich mal mit einem Ja, wenn wir zu allen Apps nur die zählen, die nicht sowieso schon auf dem Browser laufen. Offline Anwendungen können schon länger entwickelt werden (PWA) und in Zukunft soll das nicht mehr per offenem JavaScript ablaufen, sondern in kompilierter Form (Bytecode) als WebAssembly und damit sprachunabhängig, womit auch die zweite Frage beantwortet wäre. Hier gibt es einen Compiler für Java. Ob sich WebAssembly (oder doch etwas anderes) durchsetzen wird, ist noch offen, aber in meinen Augen ist klar, wohin die Reise geht.



Von WebAssembly hoert man ja immer wieder was und auch das Java da mitspielen soll. So richtig kann ich mir aber noch nicht vorstellen wie eine "komplexe Anwendung" damit entwickelt wird und wie der Workflow und die technischen Details aussehen werden. Gibt es schon ernstzunehmende Beispielprojekte die man sich anschauen sollte um einen besseren Ueberblick zu bekommen?


----------



## mihe7 (26. Aug 2019)

sirbender hat gesagt.:


> Von WebAssembly hoert man ja immer wieder was und auch das Java da mitspielen soll.


Java hat damit gar nichts zu tun. Von der Website, die ich oben verlinkt habe: "WebAssembly (abbreviated _Wasm_) is a binary instruction format for a stack-based virtual machine." Das läuft also zu Java nicht ganz unähnlich ab, aber das können Dir andere wesentlich besser erklären:




Dort erzählt er auch ein wenig über ernst zu nehmende Projekte (ich denke mal, AutoCAD kann man als ernst zu nehmend bezeichnen...)


----------



## kneitzel (26. Aug 2019)

mihe7 hat gesagt.:


> Mit dem Framework oder nur den Komponenten?


Das Framework habe ich eine Zeit direkt genutzt, ehe ich dann nach gewissen Tests auf die Cuba Platform gewechselt bin. Aber da tickt dann Vaadin drunter.

Hatte mir diverse Möglichkeiten angesehen. Angular hatte ich zuerst angesehen, aber da bin ich nicht wirklich mit Spring glücklich geworden (Aber evtl. war ich auch einfach zu ungeduldig - aber ich bin da nicht wirklich zurecht gekommen muss ich gestehen. Bei .Net kenne ich da eine gute Integration aber bei Spring fehlte mir das total.) React war auch noch ein Kandidat, den ich etwas näher betrachtet hatte ... 

Ach ja - ganz angefangen hatte ich ohne großes Framwork: Thymeleaf als Template Engine und dann halt DataTables.net (mit dem Editor, den ich mir lizensiert hatte) und Daten dann auch stark per REST in die Tabellen geladen und so ...


----------



## dzim (2. Sep 2019)

Zum Thema JavaFX auf mobilen Geräten und Da ich mal erwähnt wurde (und sorry, dass ich im Moment etwas inaktiv bin): Ausser etwas Produktpflege habe ich im Moment nichts zu vermelden. Soweit ich es verstehe, will Gluon mehr oder weniger den gesamten Plugin-Zoo etwas konsolidieren. Ich glaube, das Ziel ist, ein OpenJFX-Plugin für alle Plattformen zu haben und das bisherige javafxmobile-Plugin auszufaden. So hab ich jedenfalls einige der Tweets vom Gluon-Chef und JavaFX-Co-Lead Johan Vos verstanden.
Ich bin anfangs Dezember wieder auf den JavaFX-Days in Zürich, wo u.a. er etwas zum Thema präsentieren wird. Eventuell hab ich dann etwas zu berichten oder es gibt dann zeitnah die Talks auf YouTube oder so. Ich würde dann vielleicht mal einen separaten Thread zum Thema verfassen.
Momentan bin ich zwar auf Mobile unterwegs, aber mit Dart/Flutter, statt JavaFX.


----------



## dzim (2. Sep 2019)

Nachtrag: die JPro-Leute präsentieren wohl auch wieder, aber die sind etwas chaotisch (waren sie jedenfalls letztes Jahr). JPro läuft wohl ganz gut mit all den verschiedenen Platformen (also dass man eine App für Desktop, Mobile und Web erstellen kann), solange man im Mobile-Bereich Gluon-Charm nicht braucht. Das scheint im Moment JPro wohl nicht so gut hinzubekommen.


----------



## kneitzel (2. Sep 2019)

Ich möchte da auch noch kurz etwas zu schreiben. Heute hatten wir von der Abteilung eine nette Versammlung, im Rahmen dessen es einen interessanten Einblick in ein Projekt gab, welches von einer Gruppe durchgeführt wurde:

Bei den Aussagen des UXUI Experten fand ich das Vorgehen interessant ... wie die da die ganze Bedienung vorab planen, damit ‚spielen‘ und was da alles berücksichtigt wird. Da waren dann auch ganz klar die Vorgaben von Apple bezüglich iOS Bedienung/Aussehen sowie das Gleiche auf Android Seite von Google. Ich werde morgen schauen, ob ich da noch Aussagen bezüglich Multi Platform Frameworks bekommen kann (die waren halt nie im Fokus), denn der Kollege hat in dem Bereich halt viel Erfahrung und kann da evtl noch eine Einschätzung geben ....

Da im Projekt war aber dann jeweils native Android und native iOS Entwicklung (mit jeweils einem nem Entwickler mit Erfahrung in dem Bereich). Die Hauptarbeit war aber im Backend Bereich (mehrere Microservices mit RabbitMQ als Bus dahinter und so) ... 

Das ist also eine Herangehensweise, wie ich sie jetzt gesehen habe .... vielleicht gibt es da morgen Abend etwas mehr zu ....


----------



## sirbender (5. Sep 2019)

Ich habe mal die JavaFxPorts und Gluon Samples durchgespielt. Erstere sind super simpel und der build ist meistens broken - man muss rumspielen dann lief das Meiste. 

Die Gluon samples - kommerziell - sind deutlich komplexer und der build ist auch nicht broken. Leider ist die Performance super mies. Auch die GluonVM samples (mit der VM soll alles schneller sein) waren sehr zaeh. Ich habe auf einem Nexus4 getestet - mit Absicht, weil ich sehen wollte wie es da performed. Mit meinem S9 ist es bestimmt akzeptabel schnell aber wenn es auf dem N4 so grottenlahm ist (Start und Bedienung), dann lass ich erstmal die Finger davon. Schade eigentlich...sah nett aus


----------



## dzim (6. Sep 2019)

Krass ist der Unterschied Android <-> iOS - wenn es erst mal läuft, rennt es auf iOS wie blöde! 

Das Nexus 4 ist defintiv nicht mehr ein Target. MinSDK bei neueren Versionen des Plugins is API Level 24 (also Android 7). Auf unserem Nexus 5 (das aber auch mit Flutter schon langsam läuft) ist es auch kein Spass mehr. Bedenke einfach: Altes Gerät und fragmentierter Speicher = kein Vergnügen, egal mit welchem Framework.

Demnächst (was auch immer das bedeutet) soll auch für Android ein Preview der neuen und auf GraalVM aufsetzenden Variante folgen. Es soll wohl Java(FX)-13-Code fit für Android und iOS (und natürlich auch Desktop) machen.


----------



## dzim (6. Sep 2019)

@sirbender JavaFX für Desktop ist aber übrigens immer eine Überlegung wert! Ich persönlich finde es dort sehr gut aufgestellt. Für's Mobile muss man halt abwarten, wie's sich in näherer Zukunft entwickelt, aber so schlimm sieht's eigentlich gar nicht aus.


----------



## Trjavnamen (6. Sep 2019)

Jetzt mal ganz doof in die Runde! Wenn Java im jedem Betriebsystem läuft und sei es mit Browser.Wieso sollte man sich dann noch mit anderen Betriebsystemen auseinandersetzen? Das ist doch nur dann Notwendig wenn man eine App.erstellen will oder?


----------



## dzim (6. Sep 2019)

@Trjavnamen Tut mir leid, aber deine Frage ergibt für mich keinen Sinn! Was genau möchtest du wissen?


----------



## White_Fox (6. Sep 2019)

dzim hat gesagt.:


> JavaFX für Desktop ist aber übrigens immer eine Überlegung wert!


Das kann ich bestätigen. Es sieht klasse aus, und macht mir gerade sehr großen Spaß.


----------



## sirbender (7. Sep 2019)

dzim hat gesagt.:


> Das Nexus 4 ist defintiv nicht mehr ein Target. MinSDK bei neueren Versionen des Plugins is API Level 24 (also Android 7).



Natuerlich mit LOS 15.1 == Android 8.1. Nunja, ich teste auf dem Geraet viele Apps und normale Android Apps laufen da sehr schnell. Schon sehr bedenklich wenn JavaFX da so kriecht. Weiss jemand waurm das so ist? Nutzt JavaFX nicht einfach eine Android "surface" auf die es UI Elemente "zeichnet" und das Android Event handling...womit alles genauso schnell sein sollte wie die native Android UI?
Irgendwas scheinen die anderst zu machen? Der Startup dauert ewig und die UI reagiert extrem traege. Was laeuft da technisch ab, dass es so lahm ist?



dzim hat gesagt.:


> Demnächst (was auch immer das bedeutet) soll auch für Android ein Preview der neuen und auf GraalVM aufsetzenden Variante folgen. Es soll wohl Java(FX)-13-Code fit für Android und iOS (und natürlich auch Desktop) machen.



Ja ich weiss. Hier gibt es ein paar Samples die aber soweit ich das sehe nur auf dem Desktop laufen: https://github.com/gluonhq/client-samples

Bzw. genauer gesagt auch auf iOS: Linux, Mac OS X, iOS simulator and iOS devices

Android fehlt komischerweise (noch?) im Gradle build script. Irgendwie kann ich mir nicht vorstellen, dass fuer Android "nativ" mit GraalVM AOT kompiliert werden soll. Bei Android aendert sich nichts durch die Nutzung von GraalVM, richtig?


----------



## dzim (9. Sep 2019)

sirbender hat gesagt.:


> Weiss jemand waurm das so ist? Nutzt JavaFX nicht einfach eine Android "surface" auf die es UI Elemente "zeichnet" und das Android Event handling...womit alles genauso schnell sein sollte wie die native Android UI?


Soweit ich weiss wird dort ein SurfaceView verwendet und via native Code direkt das UI per OpenGL gerendert (so wie es auch auf Linux und im Moment auch auf Mac ist - mal vom GTK-/Cocoa-Fenster drum herum jeweils abgesehen).
Erfahrungsgemäß variiert die Performance recht start, gerade auf älteren Geräten - ich vermute, dass hier evtl. noch immer zu viel über die CPU gemacht wird. Am besten stelle die Frage mal auf StackOverflow - früher waren die Kollegen dort recht schnell, wenn sie korrekt getagt waren.



sirbender hat gesagt.:


> Ja ich weiss. Hier gibt es ein paar Samples die aber soweit ich das sehe nur auf dem Desktop laufen: https://github.com/gluonhq/client-samples


Wenn ich es richtig sehe, sollte https://github.com/gluonhq/client-samples/tree/master/Maven/HelloGluon (bzw. `.../Gradle/...`) auch auf Android laufen. Aber ich gebe zu: Ich habe es noch nicht damit ausprobiert.
Es *kann* jedoch sein, dass sie bei Android wirklich noch nicht soweit sind (siehe News https://gluonhq.com/java-on-ios-for-real/ und dem Tweet hier 



__ https://twitter.com/i/web/status/1156857867305181185).

Und doch: Es ändert sich etwas. Android ist *nicht* kompatibel zu Java 9+ Code (local type inference, switch expressions, etc.). Kotlin zaubert da zwar drum herum, aber der Bytecode ist immer noch auf Java-8-Basis. Gluon aber verspricht eben, modernes Java (und deren APIs!) auf Android lauffähig zu machen. Wie es aber genau laufen soll... Keine Ahnung. Ich hoffe, dass ich da auf dem Talk im Dezember etwas mehr von Gluon erfahre.


----------



## Trjavnamen (13. Sep 2019)

Wenn ich das richtig verstehe ist jede Enwicklungsumgebung kostenlos zu erhalten also auch Scenebuilder 2 und Java aber sobald man damit Geld verdienen will muß man dafür eine Lizenz kaufen. Richtig? Gluon SceneBuilder ist eine Kombination von 2 Grundsystemen.  Java (Orakel)und Framwork(Microsoft) Also muß man von Java eine und Cluon eine Lizenz kaufen: Richtig?


----------



## mihe7 (13. Sep 2019)

Trjavnamen hat gesagt.:


> Wenn ich das richtig verstehe ist jede Enwicklungsumgebung kostenlos zu erhalten also auch Scenebuilder 2 und Java aber sobald man damit Geld verdienen will muß man dafür eine Lizenz kaufen. Richtig? Gluon SceneBuilder ist eine Kombination von 2 Grundsystemen.  Java (Orakel)und Framwork(Microsoft) Also muß man von Java eine und Cluon eine Lizenz kaufen: Richtig?


Nein. Scene Builder 11 ist unter BSD verfügbar und bei Java kommt es darauf an, welches Produkt Du wählst. Du kannst eine freie Variante (OpenJDK-Builds verschiedener Hersteller, darunter auch Oracle OpenJDK, AdoptOpenJDK, Azul) verwenden. Alternativ kannst Du Dir kostenpflichtigen Support besorgen. Bei Oracle heißt das jetzt "Oracle Java".


----------

