Ausführbare Datei aus JavaFX Projekt erstellen

[nicothestudent]

Hallo,
ich habe ein kleines Programm mit JavaFX geschrieben, nun möchte ich aber nicht immer erst IntelliJ starten um mein Programm auszuführen, daher möchte ich eine .exe, .jar, .dmg Datei aus dem Programm machen.
Ich nutze die JavaFX-sdk-11.0.2 und als Projekt SDK Java 12.

Wäre über eine kleine Anleitung oder eine Verlinkung einer hilfreichen Anleitung sehr dankbar.

MfG

 

[Thallius]

Schau dir mal die Artifakts an in ItelliJi. Ist eigentlich recht selbsterklärend

 

[nicothestudent]

Schau dir mal die Artifakts an in ItelliJi. Ist eigentlich recht selbsterklärend

Leider funktioniert das bauen der Artifakts nicht mehr mit Versionen ab Java11.

 

[mrBrown]

Nutzt du irgendein Build-Tool und nutzt du das Modulsystem?

 

[dzim]

Ich hätte da mal was bei mir auf Arbeit vorbereitet... Muss ich mal abklären, ob ich das teilen kann.
Gestestet mit Java & JavaFX 11 und 12. Jeweils AdoptOpenJDK. OpenJFX und Kotlin via Maven-Dependency. Das Ganze macht dann mittels JLink eine maßgeschneiderte Runtime (bzw. ein Image), dass dann mit dem Early Access jpackager (ein OpenJDK 14 ea build) eine selbstständig lauffähige Applikation für den Desktop erstellt (in etwa so wie es früher der javapackager in Java 8 gemacht hat).

Etwas einfacher könnte es allerdings hiermit gehen: https://github.com/gluonhq/client-samples
Konkret das Beispiel für die FXML-Integration: https://github.com/gluonhq/client-samples/tree/master/Gradle/HelloFXML
Damit wird wohl eine einzelne Executable mittels GraalVM erstellt und sollte Desktop (alle Plattformen), sowie iOS unterstützen. Leider noch nicht Android.
Disclaimer: Ich hab es allerdings noch nicht selbst ausprobiert.

 

[nicothestudent]

Ich hätte da mal was bei mir auf Arbeit vorbereitet... Muss ich mal abklären, ob ich das teilen kann.
Gestestet mit Java & JavaFX 11 und 12. Jeweils AdoptOpenJDK. OpenJFX und Kotlin via Maven-Dependency. Das Ganze macht dann mittels JLink eine maßgeschneiderte Runtime (bzw. ein Image), dass dann mit dem Early Access jpackager (ein OpenJDK 14 ea build) eine selbstständig lauffähige Applikation für den Desktop erstellt (in etwa so wie es früher der javapackager in Java 8 gemacht hat).

Etwas einfacher könnte es allerdings hiermit gehen: https://github.com/gluonhq/client-samples
Konkret das Beispiel für die FXML-Integration: https://github.com/gluonhq/client-samples/tree/master/Gradle/HelloFXML
Damit wird wohl eine einzelne Executable mittels GraalVM erstellt und sollte Desktop (alle Plattformen), sowie iOS unterstützen. Leider noch nicht Android.
Disclaimer: Ich hab es allerdings noch nicht selbst ausprobiert.

Ich werde es so mal probieren, danke dir

 

[nicothestudent]

Nutzt du irgendein Build-Tool und nutzt du das Modulsystem?

Ich benutze kein Build-Tool aber das Modulsystem

 

[dzim]

In dem Fall musst du die Module von OpenJFX installieren: https://openjfx.io/openjfx-docs/#modular
Oder eben ZuluFX von Azul Systems.

Ich würde dir generell aber empfehlen, eher früher als später, dich mit einem Buildsystem, sei es Maven oder Gradle, anzufreunden. Langfristig macht dir das das Leben leichter.

 

[Thallius]

Leider funktioniert das bauen der Artifakts nicht mehr mit Versionen ab Java11.

Danke für die Warnung. Ein Grund mehr bei Java 8 zu bleiben.

 

[mrBrown]

Danke für die Warnung. Ein Grund mehr bei Java 8 zu bleiben.

In jedem auch nur halbwegs professionellen Umfeld nutzt doch niemand für sowas die IDE...

Aber auch unter 11 funktioniert das noch mit IntellIJ, nur kann man damit eben keine Multi-Module-Jars bauen, weil Java keine Multi-Module-Jars kann.

 

[Thallius]

In jedem auch nur halbwegs professionellen Umfeld nutzt doch niemand für sowas die IDE...

Aber auch unter 11 funktioniert das noch mit IntellIJ, nur kann man damit eben keine Multi-Module-Jars bauen, weil Java keine Multi-Module-Jars kann.

Ich nutze Java auch nicht wirklich professionell. Wenn ich mal schnell ein Tool brauche ist es gut.
Professionell setze ich lieber auf Web Entwicklung mit Javascript und Backend mit PHP oder NodeJS. Je nachdem was gefordert wird.

 

[dzim]

Also einmal richtig aufgesetzt macht ein Buildsystem für dich eigentlich die ganze Arbeit. Selbst für Basteleien würde ich bei neuen Projekten nicht mehr auf das veraltete Java 8 setzen. Und Java ohne Maven oder Gradle kommt mir eh nicht unter.

Wir haben Java 8 nur noch für "legacy"-Systeme im Einsatz, aber auch hier ist mittelfristig der Wechsel auf 11 geplant (oder 14, wenn das früher da sein sollte, als wir soweit sind ).

 

[lam_tr]

Also einmal richtig aufgesetzt macht ein Buildsystem für dich eigentlich die ganze Arbeit. Selbst für Basteleien würde ich bei neuen Projekten nicht mehr auf das veraltete Java 8 setzen. Und Java ohne Maven oder Gradle kommt mir eh nicht unter.

Wir haben Java 8 nur noch für "legacy"-Systeme im Einsatz, aber auch hier ist mittelfristig der Wechsel auf 11 geplant (oder 14, wenn das früher da sein sollte, als wir soweit sind ).

Hallo dzim,

ist an der Stelle lieber ein Wechsel auf 11 oder auf das neuste besser? ich weiß dass der Support von 11 länger dauert. Lohnt sich jedes halbe Jahr auf die neue Version zu gehen?

Grüße
lam

 

[mrBrown]

Wechsel auf 11 oder auf das neuste besser? ich weiß dass der Support von 11 länger dauert. Lohnt sich jedes halbe Jahr auf die neue Version zu gehen?

Hängt vom Umfeld und der Art des Deployments ab.
Wenn die Entwicklung jeweils auf das neuste wechseln kann und dir Runtime zusammen mit dem Programm ausgeliefert wird, kann man recht gefahrlos die neuste Version nutzen.
Wenn man aber irgendwo von externen Umgebungen abhängt, würde ich jeweils bei der neusten LTS bleiben, aktuell also 11. Die Nutzer können dann die von ihnen bevorzugte Version nutzen.

In beiden Fällen ist es aber sinnvoll, alle Versionen in die Tests mit einzubeziehen, wobei alle Versionen alle die sind, die noch Support haben und mindestens die Zielversion sind.

Aktuell also (je nach Zielversion): 8, 11, 13, 14 (als early access).
Die Zwischenversionen kann man zusätzlich mit rein nehmen, aktuell zB 12, sollte aber kaum noch Nutzer haben und durch 11 und 13 abgedeckt sein.

 

[lam_tr]

Hängt vom Umfeld und der Art des Deployments ab.
Wenn die Entwicklung jeweils auf das neuste wechseln kann und dir Runtime zusammen mit dem Programm ausgeliefert wird, kann man recht gefahrlos die neuste Version nutzen.
Wenn man aber irgendwo von externen Umgebungen abhängt, würde ich jeweils bei der neusten LTS bleiben, aktuell also 11. Die Nutzer können dann die von ihnen bevorzugte Version nutzen.

In beiden Fällen ist es aber sinnvoll, alle Versionen in die Tests mit einzubeziehen, wobei alle Versionen alle die sind, die noch Support haben und mindestens die Zielversion sind.

Aktuell also (je nach Zielversion): 8, 11, 13, 14 (als early access).
Die Zwischenversionen kann man zusätzlich mit rein nehmen, aktuell zB 12, sollte aber kaum noch Nutzer haben und durch 11 und 13 abgedeckt sein.

Und die OpenJFX ist unabhängig von OpenJDK Version ab 11 oder? Das war auch der Sinn von der Trennung.

 

[mrBrown]

Und die OpenJFX ist unabhängig von OpenJDK Version ab 11 oder? Das war auch der Sinn von der Trennung.

Ja, JFX 13 läuft afaik auch mit Java 11, @dzim hat aber irgendwo durchblicken lassen, dass es Probleme machen kann, der kann sicher mehr sagen

 

[dzim]

Problem ist aber: Ein LTS von Java 11 zu bekommen, ist nicht schwer (z.B. AdoptOpenJDK), aber für ein OpenJFX 11 LTS musst du bei Gluon löhnen. Es lohnt sich also eigentlich nicht, auf 11 zu bleiben, sondern immer aktuell zu bleiben.

Des weiteren haben die Gluon-Leute gesagt, dass sie nur eine Kompatibilität von OpenJFX X zur Java-Version X und X-1 garantieren wollen (damit man z.B. auch OpenJFX-EA-Builds der nächsten Version mit der gerade aktuellen Java-Version testen kann). Darüber hinaus ist das nicht gegeben und ich habe es, ehrlich gesagt, auch nie probiert, sonder habe es immer so eingerichtet, dass ich die selben Versionen auf beiden genutzt habe.

 

[mrBrown]

Des weiteren haben die Gluon-Leute gesagt, dass sie nur eine Kompatibilität von OpenJFX X zur Java-Version X und X-1 garantieren wollen (damit man z.B. auch OpenJFX-EA-Builds der nächsten Version mit der gerade aktuellen Java-Version testen kann). Darüber hinaus ist das nicht gegeben und ich habe es, ehrlich gesagt, auch nie probiert, sonder habe es immer so eingerichtet, dass ich die selben Versionen auf beiden genutzt habe.

Gibts da nen Blog-Post oder so von denen zu? Die Hintergründe würden mich interessieren

 

[dzim]

Ich suche morgen Mal nach, OK?

 

[dzim]

Endlich mal gesucht: Kann es nicht (mehr) finden. Also nehmt diese Info von mir gebotener Vorsicht. Vermutlich kann man Problemlos JavaFX 11 auf JDK 13, und so weiter, laufen lassen.
Andersherum hängt es wohl eher davon ab, ob in den neueren JavaFX-Builds neue Java-Features oder -APIs verwendet werden. In dem Fall wird es Exceptions geben, aber ihr könntet das ja einfach schnell selbst ausprobieren...

 

[mrBrown]

Andersherum hängt es wohl eher davon ab, ob in den neueren JavaFX-Builds neue Java-Features oder -APIs verwendet werden. In dem Fall wird es Exceptions geben, aber ihr könntet das ja einfach schnell selbst ausprobieren...

Dann sollte die Java-Version aber sowieso nicht mehr kompatibel sein, und der Build dann schon fehlschlagen?

Zumindest ein kleines Hallo World läuft mit 13 unter 11.

 

[dzim]

@mrBrown FX13 unter Java 11? Oder umgekehrt?

 

[mrBrown]

@mrBrown FX13 unter Java 11? Oder umgekehrt?

Ja, Fx 13 unter Java 11 (wobei andersrum auch klappen sollte)