JavaFX und Java 11: Bereitstellung der externen Module bei Programmabgabe

[Michae1]

Hallo,

ich weiß, es ist kein Java Forum hier aber aus der Vergangenheit weiß ich, dass hier auch einige Java-Entwickler mitlesen und mir ggf. weiterhelfen können.

Ich habe begonnen, mich in JavaFX ein wenig einzuarbeiten, da SWING auf 4K-Bildschirmen keine Option mehr ist. In Java 10 war JavaFX noch Teil des SDKs. Durch die Modularisierung des SDKs ist JavaFX nicht mehr Bestandteil von Java in der Version 11 und wird separat entwickelt.

Ich habe im Netz Tutorials gefunden, die mir erklären, wie ich bei der Entwicklung von Applikationen mit dieser Modularisierung umgehen kann. Dies konnte ich soweit auch nachvollziehen. Was ich im Moment aber nicht direkt nachvollziehen kann ist, wie man ein fertiges kompiliertes Programm für einen Endanwender bereitstellt.

Unter Java 10 war JavaFX noch Teil des SDK und der Endanwender musste lediglich die Laufzeitumgebung installiert haben. Die erstellte Applikation konnte dann direkt ausgeführt werden.

Wie sieht dies Szenarium unter Java 11 aus? Der Endanwender verfügt nun nicht mehr über die JavaFX-Erweiterung, wenn dieser das SDK-11 installiert hat. Sind jetzt zusätzlich zur eigentlichen Applikation auch die JavaFX-Module mit auszuliefern/bereitzustellen? Meine Applikation benötigt derzeit kaum Speicher. Das JavaFX-Modul für Windows ist allein schon > 70 MB groß. Dies ist 10-mal mehr als meine Anwendung.

Ausgehend davon, dass das JavaFX-Modul mit beigelegt werden muss, wie erhält man die Plattformunabhängigkeit? Das Modul wird für verschiedene Plattformen zusammen mit nativen Files bereitgestellt. Die jar-Files in den plattformabhängigen Paketen sind nicht identisch. Muss nun für jede Plattform, die unterstützt werden soll, das Programm separat vorgehalten werden?

Viele Grüße Michae1

[ursus contionabundo]

Das JavaFX-Modul für Windows ist allein schon > 70 MB groß. Dies ist 10-mal mehr als meine Anwendung.

Tja. Dat muss so.

Wie sieht dies Szenarium unter Java 11 aus?

Oracle hat eigentlich alles beantwortet. Getting started.

[Michae1]

Hallo ursus contionabundo,

vielen Dank für Deine schnelle Rückmeldung. Wenn ich das richtig verstehe - und ich würde mich sehr freuen, wenn Du mir das besteigen (oder dementieren) könntest - , dann ist pro Plattform nun tatsächlich eine Version zu erzeugen, vgl. 2.3.1 Self-Contained Applications. Die unter 2.4 Packaging Tools angegebenen Lösungen würden mir die Arbeit mit den Abhängigkeiten zwischen den Plattformen zwar abnehmen, erzeugen im Endeffekt dann aber trotzdem pro Plattform eine Version, oder?

Viele Grüße Michae1

[ursus contionabundo]

Du meinst:

2.3.1 Self-Contained Applications

Starting from JDK 7 update 6, JavaFX applications can be packaged as a platform-specific, self-contained application. These applications include all application resources, the Java and JavaFX runtimes, and a launcher, and they provide the same install and launch experience as native applications for the operating system.

Self-contained applications can be distributed as zip files or as installable packages: EXE or MSI for Windows, DMG for Mac, or RPM or DEB for Linux.

Das meint: "Sowas geht." Aber die klassischen jar-Files funktionieren trotzdem - wenn auf den Rechnern eine JRE mit JavaFX als lib vorhanden ist oder wenn Du diese wie eigene libs mit einbindest.

[Michae1]

Hallo,

oder wenn Du diese wie eigene libs mit einbindest

Was ich doch letztlich ab Java 11 für FX alternativlos tun muss, oder? Das man eine Plattform übergreifende Applikation erstellen kann, habe ich nicht direkt gefunden oder herauslesen können.

Viele Grüße Michae1

[ursus contionabundo]

Versuch doch einfach mal Dein(e) jar-File(s) auf einer (virtuellen) Maschine auszuführen, die nur die JRE und darin JavaFX installiert hat...

Das libs (z.B. für den Datenbankzugriff) vorhanden sein müssen war schon immer so.

Für mich sieht so aus als bräuchte man im JRE:

… /jre/lib/ext/jfxrt.jar
… /jre/lib/javafx.properties
… /jre/lib/jfxswt.jar
… /lib/ant-javafx.jar
… /lib/javafx-mx.jar

Wenn Du aber bisher schon Standalone-Applications (.exe, ...) erzeugt und ausgeliefert hast, dann ist der Packer dafür zuständig, neben dem Deinem Prälompilat-Zeug auch die eingebunden, also benötigten(!) libs und natürlich den Java-Interpreter zu liefern. In dem Fall ist kundenseitig nichts weiter zu tun. Aber das ist dann eben OS-spezifisch zu erzeugen und die Pakete sind natürlich größer als wenn eine mit den benötigten libs ausgestattete JRE vorhanden ist und genutzt wird.

Aber wenn ich ehrlich bin, werde ich wohl keine große Hilfe sein. Denn ich weiß weniger über Java als viele andere schon vergessen haben.

[Michae1]

Hallo,

Versuch doch einfach mal Dein(e) jar-File(s) auf einer (virtuellen) Maschine auszuführen, die nur die JRE und darin JavaFX installiert hat...

JavaFX ist nicht mehr Teil des SDKs, sodass dies ein manuelles Nachinstallieren erfordert. Dies will ich dem Endanwender nicht auferlegen. Das von Dir beschriebene Szenario funktioniert, wie man durch Verwendung von Java 9 und 10 leicht verifizieren kann.

Das libs (z.B. für den Datenbankzugriff) vorhanden sein müssen war schon immer so.

Ja, aber diese waren meist nicht abhängig von der Plattform. Ich kann bspw. - um bei Deinen Beispiel zu bleiben - die hsqldb.jar in den CLASSPATH legen. Diese Bibliothek wird dann von allen OS einheitlich akzeptiert.

Wenn Du aber bisher schon Standalone-Applications (.exe, ...) erzeugt und ausgeliefert hast, dann ist der Packer dafür zuständig, neben dem Deinem Prälompilat-Zeug auch die eingebunden, also benötigten(!) libs und natürlich den Java-Interpreter zu liefern.

Bisher habe ich einfach meinen Kram (inkls. der externen Bibliotheken) kompiliert und ausgeliefert. Bezüglich der Plattform beim Endanwender musste ich mir keine Gedanken machen. Insofern war es nicht nötig, plattformspezifische Anwendungen zu erzeugen; und eigentlich würde ich dies auch gern vermeiden - aber wie?

Wenn die die JARs von JavaFX einheitlich wären, wäre es vermutlich recht einfach. Da diese scheinbar auch plattformspezifisch sind, hätte ich gleichnamige JARs, die nicht kombinierbar sind. Ich verstehe daher nicht, wie in diesem Video-Tutorial Maven mit den unterschiedlichen aber gleichnamigen JARs umgeht.

Aber wenn ich ehrlich bin, werde ich wohl keine große Hilfe sein.

Du bist immerhin der einzige, der überhaupt hilft. ;-) Insofern bin ich für jeden Vorschlag offen.

Viele Grüße Michae1