# Ausführbare Datei aus JavaFX Projekt erstellen



## nicothestudent (22. Sep 2019)

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 (22. Sep 2019)

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


----------



## nicothestudent (22. Sep 2019)

Thallius hat gesagt.:


> 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 (22. Sep 2019)

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


----------



## dzim (23. Sep 2019)

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 (25. Sep 2019)

dzim hat gesagt.:


> 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
> ...


Ich werde es so mal probieren, danke dir


----------



## nicothestudent (25. Sep 2019)

mrBrown hat gesagt.:


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


Ich benutze kein Build-Tool aber das Modulsystem


----------



## dzim (25. Sep 2019)

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 (25. Sep 2019)

nicothestudent hat gesagt.:


> 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 (25. Sep 2019)

Thallius hat gesagt.:


> 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 (25. Sep 2019)

mrBrown hat gesagt.:


> 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 (25. Sep 2019)

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 (26. Sep 2019)

dzim hat gesagt.:


> 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 (26. Sep 2019)

lam_tr hat gesagt.:


> 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 (26. Sep 2019)

mrBrown hat gesagt.:


> 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.
> 
> ...


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


----------



## mrBrown (26. Sep 2019)

lam_tr hat gesagt.:


> 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 (27. Sep 2019)

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 (27. Sep 2019)

dzim hat gesagt.:


> 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 (28. Sep 2019)

Ich suche morgen Mal nach, OK?


----------



## dzim (30. Sep 2019)

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 (30. Sep 2019)

dzim hat gesagt.:


> 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 (30. Sep 2019)

@mrBrown FX13 unter Java 11? Oder umgekehrt?


----------



## mrBrown (30. Sep 2019)

dzim hat gesagt.:


> @mrBrown FX13 unter Java 11? Oder umgekehrt?


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


----------

