Aus einer jar-Datei eine exe-Datei erzeugen lassen

[Zrebna]

Hallo!

Ich habe eine simple hello_world_app-1.0-SNAPSHOT.jar-Datei.
Ziel ist es ein Java-Programm zu schreiben, das aus jar-Dateien ausführbare exe-Dateien erzeugt, wobei 2 Kriterein beachtet werden müssen.
1. Die erzeugten exe-Dateien müssen nicht nur auf Windows, sondern auch auf Linux und maxOS laufen können.
2. Der User, der dann die exe aus seinem Rechner laufen lässt, muss nicht Java installiert haben.

Welche Tools sind für dieses Vorhaben am besten geeignet?
Launch4j, jpackage (ab JDK 14), ...?

 

[KonradN]

1. Die erzeugten exe-Dateien müssen nicht nur auf Windows, sondern auch auf Linux und maxOS laufen können.

Also exe Dateien laufen erst einmal nur auf Windows. Linux und macos nutzen nicht das PE Format von Windows. Du wirst also mehrere Executables nutzen müssen.

2. Der User, der dann die exe aus seinem Rechner laufen lässt, muss nicht Java installiert haben.

Das funktioniert auf zwei Wegen:
a) Du kannst ein JRE mitgeben. Das ist, was JLink / JPackage machen. Das funktioniert relativ gut, da Du halt unter dem Strich nichts besonderes machst bezüglich dem Start des Java Codes.
b) Eine Überlegung kann sein, dass Du aus dem Java Code wirkliche Binaries machst. Du nutzt also keine Java Virtual Machine mehr. Diesbezüglich gab es mal im GNU Umfeld einen Compiler aber das ist wohl eingestellt worden (Hier kann ich mich aber auch durchaus irren) und das Produkt GraalVM von Oracle geht in die gleiche Richtung. Da ist dann aber zur Laufzeit einiges anders und Du hast dann z.B. nicht mehr den typischen Classpath zum laden von Klassen und so. Und es erfordert eine volle Build Umgebung auf dem System.

Das wären so die üblichen Wege. Lauch4j stellt nur einen Wrapper und erwartet eine Java Installation (die aber auch in einem direkten Unterverzeichnis sein kann).

Derzeit üblich wäre hier vermutlich daher der jpackage Weg. Um die Plattformen abzudecken kann man dann ci/cd Pipelines nutzen um es auf allen Systemen zu übersetzen. So kannst Du dann die Deliveries kriegen für jede Plattform.

 

[Marinek]

Ich möchte hier anfügen, dass die gesamte Welt von Desktop zu Web und Cloudanwenwendungen geht.

In Spezialfällen kann es auch Desktop Apps geben. Aber ich denke damit wird man kein Geld verdienen.

 

[Oneixee5]

Ich verstehe es auch nicht. Wie kommt man darauf, Desktop-Anwendungen auf Basis von Java zu entwickeln? Java macht nur Sinn in Server- und Cloud-Umgebungen.

 

[KonradN]

Manche Aussagen finde ich seltsam: es gibt Eclipse, IntelliJ, Netbeans, …. Die machen auch alle keinen Sinn?

Ich denke, die Aussage ist so etwas überzogen und sollte evtl. besser formuliert werden.

 

[Marinek]

Ich denke, die Aussage ist so etwas überzogen und sollte evtl. besser formuliert werden.

Ich weiß nicht auf welche Aussage sich das bezieht... Aber ich habe Spezialfälle ja gerade nicht ausgeschlossen. Manches muss man auch nicht auf die goldene Waage stellen. Denke der TO wird das schon für sich interpretieren können, sonst kann er gerne hier Fragen stellen dazu.

 

[KonradN]

Ich weiß nicht auf welche Aussage sich das bezieht

Das bezog sich rein auf Oneixee5. Dachte eigentlich, dass dies durchaus erkennbar wäre durch den Inhalt, denn die Gegenbeispiele widerlegen ja

Java macht nur Sinn in Server- und Cloud-Umgebungen

was schlicht zu pauschal ist aus meiner Sicht.

 

[Oneixee5]

Genau, Eclipse wird hier ständig schlecht gemacht, IntelliJ hällt nicht was es verspricht und Netbeans, mal ehrlich, das Beispiel für schlechte Software über viele viele Jahre ...
Auch IDE's ziehen immer mehr in die Cloud. Die einzige Desktop-Anwendung die noch Sinn macht, ist der Browser als Plattform für die Cloud.

 

[KonradN]

Eclipse wird hier ständig schlecht gemacht

Weil ich es nicht geeignet halte für Anfänger. Und ich mag nicht diesen Ansatz einer Eierlegenden-Woll-Milch-Sau. Ändert aber nichts daran, dass es ein Produkt mit sehr viel Features ist.

IntelliJ hällt nicht was es verspricht

Was verspricht es und hält es nicht? Ich nutze es sehr gerne und in meinem Umkreis ist es die Entwicklungsumgebung, die tatsächlich von eigentlich jedem gewählt wurde.

Zu Netbeans kann ich nicht viel sagen, da ich es so gut wie gar nicht benutze. Aber ich kenne mindestens einen Entwickler, der es sehr gerne nutzt und ich bin sicher, dass er dafür auch Gründe hat ...

Auch IDE's ziehen immer mehr in die Cloud.

Das sehe ich erst einmal nicht. An was denkst Du da, wenn Du sowas sagst?

Die einzige Desktop-Anwendung die noch Sinn macht, ist der Browser als Plattform für die Cloud.

Also das sehe ich komplett anders. Klar, die Entwicklung geht in diese Richtung bei vielen Anwendungen, aber das setzt halt gewisse Dinge voraus, z.B. den Zugriff auf die Cloud.

Aber ist das denn wirklich der Punkt, um den es Dir geht? Oder ging es Dir nicht eher um Dinge wie:

• die generelle Entwicklung, die z.B. auch @Marinek angesprochen hat?
• Oder hattest Du evtl. mehr einen Blick auf geeignete Technologien? Wenn es um Desktop Anwendungen geht, dann würde ich hier auch eher nicht an Java denken

Wir sind vermutlich nicht einmal so weit auseinander mit unseren Sichtweisen, aber deine Aussage ging ein kleines bisschen zu weit.

 

[Zrebna]

Also exe Dateien laufen erst einmal nur auf Windows. Linux und macos nutzen nicht das PE Format von Windows. Du wirst also mehrere Executables nutzen müssen.

Das funktioniert auf zwei Wegen:
a) Du kannst ein JRE mitgeben. Das ist, was JLink / JPackage machen. Das funktioniert relativ gut, da Du halt unter dem Strich nichts besonderes machst bezüglich dem Start des Java Codes.

Ich habe es mal mit JPackage versucht, da kommt direkt:

Failed to create EXE file.
[10:55:55.728] WiX-Tools (light.exe, candle.exe) nicht gefunden

Da braucht man also schon noch viel zusätzlich - nicht nur dieses WiX-Toolset, sondern damit dieses laufen kann, muss man wohl auch eine .NET SDK installiert haben.

JLink kenne ich noch nicht und gucke mir das mal an.

Das Problem bei diesem Ansatz ist jedoch, dass das ganze auch klein gehalten werden soll. Wenn man eine JRE mitgibt, dann ist dies wohl diesem weiterem Ziel entgegensetzlich.

b) Eine Überlegung kann sein, dass Du aus dem Java Code wirkliche Binaries machst. Du nutzt also keine Java Virtual Machine mehr. Diesbezüglich gab es mal im GNU Umfeld einen Compiler aber das ist wohl eingestellt worden (Hier kann ich mich aber auch durchaus irren) und das Produkt GraalVM von Oracle geht in die gleiche Richtung. Da ist dann aber zur Laufzeit einiges anders und Du hast dann z.B. nicht mehr den typischen Classpath zum laden von Klassen und so. Und es erfordert eine volle Build Umgebung auf dem System.

Das wären so die üblichen Wege. Lauch4j stellt nur einen Wrapper und erwartet eine Java Installation (die aber auch in einem direkten Unterverzeichnis sein kann).

Derzeit üblich wäre hier vermutlich daher der jpackage Weg. Um die Plattformen abzudecken kann man dann ci/cd Pipelines nutzen um es auf allen Systemen zu übersetzen. So kannst Du dann die Deliveries kriegen für jede Plattform.

 

[KonradN]

Da braucht man also schon noch viel zusätzlich - nicht nur dieses WiX-Toolset, sondern damit dieses laufen kann, muss man wohl auch eine .NET SDK installiert haben.

Du kann mit JPackage zwei Dinge machen:
a) Ein MSI bauen. Dazu brauchst Du die notwendigen Tools und das ist das WIX Toolkit (Windows Installer XML). Das ist aber doch nicht, was Du hier machen wolltest.
b) Du kannst ein AppImage bauen. Dazu brauchst Du kein WIX Toolkit. Da reicht ein JDK, welches mit JPackage daher kommt.

JLink kenne ich noch nicht und gucke mir das mal an.

JLink erzeugt ein erster Image incl. JRE und benötigten Modulen. Setzt dann z.B. voraus, dass Du eine Modulbeschreibung hast. Das ist aber nicht notwendig, wenn man es nicht will.

Das Problem bei diesem Ansatz ist jedoch, dass das ganze auch klein gehalten werden soll. Wenn man eine JRE mitgibt, dann ist dies wohl diesem weiterem Ziel entgegensetzlich.

Du hast nun einmal eine Java Anwendung und für diese brauchst Du eine Java Laufzeit Umgebung. Das halt eine feste Abhängigkeit. Bei einer managed Umgebung hast Du halt genau diese Thematik - ist also auch bei der .Net Entwicklung auch nicht anders. (Nur eben hat man da mehr Wert darauf gelegt, dass man es als Systemkomponente hat. Das was also Sun auch erst wollte - aber mit sehr mäßigem Erfolg.)

Edit: Falls Du Maven einsetzt, dann willst Du evtl. einmal kneitzel/JavaMavenApp (github.com) anschauen. Dort in der pom.xml ist das Profil image mit zwei Plugins, die Dich interessieren könnten.

 

[Zrebna]

Du kann mit JPackage zwei Dinge machen:
a) Ein MSI bauen. Dazu brauchst Du die notwendigen Tools und das ist das WIX Toolkit (Windows Installer XML). Das ist aber doch nicht, was Du hier machen wolltest.
b) Du kannst ein AppImage bauen. Dazu brauchst Du kein WIX Toolkit. Da reicht ein JDK, welches mit JPackage daher kommt.


JLink erzeugt ein erster Image incl. JRE und benötigten Modulen. Setzt dann z.B. voraus, dass Du eine Modulbeschreibung hast. Das ist aber nicht notwendig, wenn man es nicht will.


Du hast nun einmal eine Java Anwendung und für diese brauchst Du eine Java Laufzeit Umgebung. Das halt eine feste Abhängigkeit. Bei einer managed Umgebung hast Du halt genau diese Thematik - ist also auch bei der .Net Entwicklung auch nicht anders. (Nur eben hat man da mehr Wert darauf gelegt, dass man es als Systemkomponente hat. Das was also Sun auch erst wollte - aber mit sehr mäßigem Erfolg.)

Edit: Falls Du Maven einsetzt, dann willst Du evtl. einmal kneitzel/JavaMavenApp (github.com) anschauen. Dort in der pom.xml ist das Profil image mit zwei Plugins, die Dich interessieren könnten.

Also was ich erstmal nur wollte ist eben aus einer jar eine exe erzeugen und das hat mittlerweile funktioniert - siehe Bild.



Ansonsten muss ich mich korrigieren, weil man bzgl. dem WiX-Tool genau die 3.x-Version braucht:
https://github.com/wixtoolset/wix3/releases/tag/wix3112rtm

Denn insbesondere benötigt jPackage die dortige light.exe und candle.exe, welche wohl nur in der 3.x-Version vorhanden sind und diese benötigt wohl das .Net-SDK nicht.

Zu dem Link zu deinem Prpjekt - das könnte interessant sein:
<!-- Profile that adds compiling to a native binary using
GraalVM an Native Image https://www.graalvm.org/

Add -Pnative or -Dnative to use this profile.
-->

In dem Fall braucht man wohl nicht mal code, der die Erzeugung aus einer jar in eine exe erledigt, sondern das passiert dann wohl automatisch beim Kompilieren - ich sehe mir das genauer an - danke.

 

[KonradN]

Im Augenblick irritiert mich das, was Du zeigst, etwas. Was genau für Parameter hast Du bei dem JPackage Aufruf angegeben?

Das sieht mir nicht nach dem üblichen AppImage aus sondern du hast vermutlich nur einen Installer in Form eine EXE gebaut (Was erklärt, dass WIX benötigt wurde). Das startet also nur eine Installation. Das erstellt keine exe, die das Programm selbst startet. Ein AppImage besteht aus mehr Dateien als nur einer EXE.

Du kannst mit JPackage aber auch ein AppImage bauen. Dann hast Du eine Verzeichnisstruktur mit allen Dateien, die Du brauchst und eine exe, die Du direkt startet kannst. Das Verzeichnis kannst Du also so weiter geben und auf dem Zielrechner brauchst Du sonst nichts weiter und kannst die EXE direkt starten.

Und das native Profil nutzt das in der ersten Antwort bereits erwähnte GraalVM mit native-image. Da hast Du deutlich mehr Anforderungen (Visual Studio unter Windows) und da wird dann wirklich eine EXE gebaut und Du hast deutlich weniger Abhängigkeiten. Aber da muss man sich auch deutlich tiefer hinein knien, da es auch Dinge gibt, die nicht mehr direkt so funktionieren, wie bisher.

 

[Zrebna]

Im Augenblick irritiert mich das, was Du zeigst, etwas. Was genau für Parameter hast Du bei dem JPackage Aufruf angegeben?

Das sieht mir nicht nach dem üblichen AppImage aus sondern du hast vermutlich nur einen Installer in Form eine EXE gebaut (Was erklärt, dass WIX benötigt wurde). Das startet also nur eine Installation. Das erstellt keine exe, die das Programm selbst startet. Ein AppImage besteht aus mehr Dateien als nur einer EXE.

Ah ok, das erklärt einiges.
Und zwar konnte ich die zugehörige jar-Datei problemlos starten und der "Hello World"-Gruß erschien - jedoch hat das nicht bei der "exe" funktioniert - diese hat wohl in der Tat die exe erst installiert? Siehe Bild.

Du kannst mit JPackage aber auch ein AppImage bauen. Dann hast Du eine Verzeichnisstruktur mit allen Dateien, die Du brauchst und eine exe, die Du direkt startet kannst. Das Verzeichnis kannst Du also so weiter geben und auf dem Zielrechner brauchst Du sonst nichts weiter und kannst die EXE direkt starten.

Entspricht die Verzeichnisstuktur, die du erwartest der in dem Bild?

Und das native Profil nutzt das in der ersten Antwort bereits erwähnte GraalVM mit native-image. Da hast Du deutlich mehr Anforderungen (Visual Studio unter Windows) und da wird dann wirklich eine EXE gebaut und Du hast deutlich weniger Abhängigkeiten. Aber da muss man sich auch deutlich tiefer hinein knien, da es auch Dinge gibt, die nicht mehr direkt so funktionieren, wie bisher.

Ja, das habe ich auch gerade gemerkt, dass da u.a. VisualStudio benötigt wird.
Trotzdem aus Interesse - welche Abhängigkeiten braucht man weniger und wäre das Endprodukt, das man ausliefern kann samt EXE, kleiner bzgl. Speicherplatz?

 

[KonradN]

Ich habe jetzt einfach einmal das JavaMavenApp mit -Pnative gebaut und das Ergebnis ist ca. 6 MB groß. Für ein HelloWorld ist das immer noch extrem, aber halt deutlich weniger, als das AppImage belegt hätte,

C:\Projects\Konrad\JavaMavenApp\target>dir
 Datenträger in Laufwerk C: ist Windows
 Volumeseriennummer: 688C-F37E

 Verzeichnis von C:\Projects\Konrad\JavaMavenApp\target

17.06.2024  09:24    <DIR>          .
17.06.2024  09:24    <DIR>          ..
17.06.2024  09:23    <DIR>          apidocs
17.06.2024  09:23    <DIR>          classes
17.06.2024  09:23    <DIR>          generated-sources
17.06.2024  09:23    <DIR>          generated-test-sources
17.06.2024  09:23    <DIR>          graalvm-reachability-metadata
17.06.2024  09:23    <DIR>          javadoc-bundle-options
17.06.2024  09:23            92.154 javamavenapp-1.0-SNAPSHOT-javadoc.jar
17.06.2024  09:23         1.537.869 javamavenapp-1.0-SNAPSHOT.jar
17.06.2024  09:24         6.254.592 javamavenapp.exe
17.06.2024  09:23    <DIR>          maven-archiver
17.06.2024  09:23             2.754 maven-javadoc-plugin-stale-data.txt
17.06.2024  09:23    <DIR>          maven-status
17.06.2024  09:23    <DIR>          pmd
17.06.2024  09:23               314 pmd.xml
17.06.2024  09:23    <DIR>          site
08.09.2022  13:40               398 spotbugs-exclude-filter.xml
17.06.2024  09:23             4.227 spotbugsXml.xml
17.06.2024  09:23    <DIR>          test-classes
17.06.2024  09:23    <DIR>          tmp
               7 Datei(en),      7.892.308 Bytes
              14 Verzeichnis(se), 452.018.241.536 Bytes frei

C:\Projects\Konrad\JavaMavenApp\target>javamavenapp.exe
Hallo Welt!

C:\Projects\Konrad\JavaMavenApp\target>

Der Build Prozess nutzte GraalVM21 für Windows 64Bit mit aktuellem Visual Studio 2022. Damit der Build richtig funktioniert, wurde es ausgeführt in dem x64 Command Prompt von Visual Studio:

**********************************************************************
** Visual Studio 2022 Developer Command Prompt v17.10.2
** Copyright (c) 2022 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'

C:\Program Files\Microsoft Visual Studio\2022\Professional>\Apps\GraalVM21.cmd

C:\Program Files\Microsoft Visual Studio\2022\Professional>cd \Projects\Konrad

C:\Projects\Konrad>cd JavaMavenApp
C:\Projects\Konrad\JavaMavenApp>mvnw -Pnative clean package
[INFO] Scanning for projects...
Downloading from central: https://repo.maven.apache.org/maven2/org/graalvm/buildtools/utils/0.10.2/utils-0.10.2.pom
Downloaded from central: https://repo.maven.apache.org/maven2/org/graalvm/buildtools/utils/0.10.2/utils-0.10.2.pom (1.9 kB at 2.4 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/com/fasterxml/jackson/core/jackson-databind/2.13.5/jackson-databind-2.13.5.pom
Downloaded from central: https://repo.maven.apache.org/maven2/com/fasterxml/jackson/core/jackson-databind/2.13.5/jackson-databind-2.13.5.pom (18 kB at 106 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/com/fasterxml/jackson/jackson-base/2.13.5/jackson-base-2.13.5.pom
Downloaded from central: https://repo.maven.apache.org/maven2/com/fasterxml/jackson/jackson-base/2.13.5/jackson-base-2.13.5.pom (10 kB at 85 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/com/fasterxml/jackson/jackson-bom/2.13.5/jackson-bom-2.13.5.pom
Downloaded from central: https://repo.maven.apache.org/maven2/com/fasterxml/jackson/jackson-bom/2.13.5/jackson-bom-2.13.5.pom (17 kB at 110 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/com/fasterxml/jackson/core/jackson-annotations/2.13.5/jackson-annotations-2.13.5.pom
Downloaded from central: https://repo.maven.apache.org/maven2/com/fasterxml/jackson/core/jackson-annotations/2.13.5/jackson-annotations-2.13.5.pom (6.1 kB at 42 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/com/fasterxml/jackson/core/jackson-core/2.13.5/jackson-core-2.13.5.pom
Downloaded from central: https://repo.maven.apache.org/maven2/com/fasterxml/jackson/core/jackson-core/2.13.5/jackson-core-2.13.5.pom (6.5 kB at 43 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/org/graalvm/buildtools/graalvm-reachability-metadata/0.10.2/graalvm-reachability-metadata-0.10.2.pom
Downloaded from central: https://repo.maven.apache.org/maven2/org/graalvm/buildtools/graalvm-reachability-metadata/0.10.2/graalvm-reachability-metadata-0.10.2.pom (2.0 kB at 17 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-xml/4.0.2/plexus-xml-4.0.2.pom
Downloaded from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-xml/4.0.2/plexus-xml-4.0.2.pom (4.2 kB at 17 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/maven-xml-impl/4.0.0-alpha-7/maven-xml-impl-4.0.0-alpha-7.pom
Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/maven/maven-xml-impl/4.0.0-alpha-7/maven-xml-impl-4.0.0-alpha-7.pom (1.9 kB at 7.9 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/maven/4.0.0-alpha-7/maven-4.0.0-alpha-7.pom
Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/maven/maven/4.0.0-alpha-7/maven-4.0.0-alpha-7.pom (26 kB at 122 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/maven-bom/4.0.0-alpha-7/maven-bom-4.0.0-alpha-7.pom
Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/maven/maven-bom/4.0.0-alpha-7/maven-bom-4.0.0-alpha-7.pom (6.3 kB at 28 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/maven-api-xml/4.0.0-alpha-7/maven-api-xml-4.0.0-alpha-7.pom
Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/maven/maven-api-xml/4.0.0-alpha-7/maven-api-xml-4.0.0-alpha-7.pom (1.6 kB at 11 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/maven-api/4.0.0-alpha-7/maven-api-4.0.0-alpha-7.pom
Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/maven/maven-api/4.0.0-alpha-7/maven-api-4.0.0-alpha-7.pom (3.6 kB at 16 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/maven-api-meta/4.0.0-alpha-7/maven-api-meta-4.0.0-alpha-7.pom
Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/maven/maven-api-meta/4.0.0-alpha-7/maven-api-meta-4.0.0-alpha-7.pom (1.4 kB at 7.7 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/org/graalvm/buildtools/native-maven-plugin/0.10.2/native-maven-plugin-0.10.2.jar
Downloading from central: https://repo.maven.apache.org/maven2/com/fasterxml/jackson/core/jackson-databind/2.13.5/jackson-databind-2.13.5.jar
Downloading from central: https://repo.maven.apache.org/maven2/org/graalvm/buildtools/utils/0.10.2/utils-0.10.2.jar
Downloading from central: https://repo.maven.apache.org/maven2/com/fasterxml/jackson/core/jackson-core/2.13.5/jackson-core-2.13.5.jar
Downloading from central: https://repo.maven.apache.org/maven2/com/fasterxml/jackson/core/jackson-annotations/2.13.5/jackson-annotations-2.13.5.jar
Downloaded from central: https://repo.maven.apache.org/maven2/org/graalvm/buildtools/utils/0.10.2/utils-0.10.2.jar (30 kB at 7.8 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/org/graalvm/buildtools/graalvm-reachability-metadata/0.10.2/graalvm-reachability-metadata-0.10.2.jar
Downloaded from central: https://repo.maven.apache.org/maven2/com/fasterxml/jackson/core/jackson-annotations/2.13.5/jackson-annotations-2.13.5.jar (76 kB at 19 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-xml/4.0.2/plexus-xml-4.0.2.jar
Downloaded from central: https://repo.maven.apache.org/maven2/org/graalvm/buildtools/graalvm-reachability-metadata/0.10.2/graalvm-reachability-metadata-0.10.2.jar (26 kB at 6.5 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/maven-xml-impl/4.0.0-alpha-7/maven-xml-impl-4.0.0-alpha-7.jar
Downloaded from central: https://repo.maven.apache.org/maven2/com/fasterxml/jackson/core/jackson-core/2.13.5/jackson-core-2.13.5.jar (375 kB at 92 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/maven-api-xml/4.0.0-alpha-7/maven-api-xml-4.0.0-alpha-7.jar
Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/maven/maven-api-xml/4.0.0-alpha-7/maven-api-xml-4.0.0-alpha-7.jar (8.4 kB at 2.0 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/maven-api-meta/4.0.0-alpha-7/maven-api-meta-4.0.0-alpha-7.jar
Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/maven/maven-xml-impl/4.0.0-alpha-7/maven-xml-impl-4.0.0-alpha-7.jar (19 kB at 4.6 kB/s)
Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/maven/maven-api-meta/4.0.0-alpha-7/maven-api-meta-4.0.0-alpha-7.jar (12 kB at 2.7 kB/s)
Downloaded from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-xml/4.0.2/plexus-xml-4.0.2.jar (89 kB at 20 kB/s)
Downloaded from central: https://repo.maven.apache.org/maven2/com/fasterxml/jackson/core/jackson-databind/2.13.5/jackson-databind-2.13.5.jar (1.5 MB at 285 kB/s)
Downloaded from central: https://repo.maven.apache.org/maven2/org/graalvm/buildtools/native-maven-plugin/0.10.2/native-maven-plugin-0.10.2.jar (86 kB at 14 kB/s)
[INFO]
[INFO] ----------------------< de.kneitzel:javamavenapp >----------------------
[INFO] Building javamavenapp 1.0-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
Downloading from central: https://repo.maven.apache.org/maven2/org/mockito/mockito-core/5.12.0/mockito-core-5.12.0.pom
Downloaded from central: https://repo.maven.apache.org/maven2/org/mockito/mockito-core/5.12.0/mockito-core-5.12.0.pom (2.5 kB at 14 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/net/bytebuddy/byte-buddy-agent/1.14.15/byte-buddy-agent-1.14.15.pom
Downloaded from central: https://repo.maven.apache.org/maven2/net/bytebuddy/byte-buddy-agent/1.14.15/byte-buddy-agent-1.14.15.pom (10 kB at 86 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/org/mockito/mockito-junit-jupiter/5.12.0/mockito-junit-jupiter-5.12.0.pom
Downloaded from central: https://repo.maven.apache.org/maven2/org/mockito/mockito-junit-jupiter/5.12.0/mockito-junit-jupiter-5.12.0.pom (2.3 kB at 14 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/org/mockito/mockito-core/5.12.0/mockito-core-5.12.0.jar
Downloading from central: https://repo.maven.apache.org/maven2/org/mockito/mockito-junit-jupiter/5.12.0/mockito-junit-jupiter-5.12.0.jar
Downloading from central: https://repo.maven.apache.org/maven2/net/bytebuddy/byte-buddy-agent/1.14.15/byte-buddy-agent-1.14.15.jar
Downloaded from central: https://repo.maven.apache.org/maven2/org/mockito/mockito-junit-jupiter/5.12.0/mockito-junit-jupiter-5.12.0.jar (8.9 kB at 36 kB/s)
Downloaded from central: https://repo.maven.apache.org/maven2/org/mockito/mockito-core/5.12.0/mockito-core-5.12.0.jar (704 kB at 1000 kB/s)
Downloaded from central: https://repo.maven.apache.org/maven2/net/bytebuddy/byte-buddy-agent/1.14.15/byte-buddy-agent-1.14.15.jar (258 kB at 318 kB/s)
[INFO]
[INFO] --- maven-clean-plugin:3.3.2:clean (default-clean) @ javamavenapp ---
[INFO] Deleting C:\Projects\Konrad\JavaMavenApp\target
[INFO]
[INFO] --- maven-enforcer-plugin:3.4.1:enforce (enforce-versions) @ javamavenapp ---
[INFO] Rule 0: org.apache.maven.enforcer.rules.version.RequireMavenVersion passed
[INFO]
[INFO] --- versions-maven-plugin:2.16.2:display-dependency-updates (default) @ javamavenapp ---
[INFO] The following dependencies in Dependencies have newer versions:
[INFO]   org.junit.jupiter:junit-jupiter-engine ........... 5.10.2 -> 5.11.0-M2
[INFO]   org.junit.jupiter:junit-jupiter-params ........... 5.10.2 -> 5.11.0-M2
[INFO]
[INFO] No dependencies in Plugin Dependencies have newer versions.
[INFO]
[INFO]
[INFO] --- versions-maven-plugin:2.16.2:display-plugin-updates (default) @ javamavenapp ---
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-javadoc-plugin/maven-metadata.xml
Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-javadoc-plugin/maven-metadata.xml (1.4 kB at 7.9 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-javadoc-plugin/3.7.0/maven-javadoc-plugin-3.7.0.pom
Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-javadoc-plugin/3.7.0/maven-javadoc-plugin-3.7.0.pom (21 kB at 182 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-project-info-reports-plugin/maven-metadata.xml
Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-project-info-reports-plugin/maven-metadata.xml (1.4 kB at 13 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-project-info-reports-plugin/3.6.0/maven-project-info-reports-plugin-3.6.0.pom
Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-project-info-reports-plugin/3.6.0/maven-project-info-reports-plugin-3.6.0.pom (19 kB at 192 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-shade-plugin/maven-metadata.xml
Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-shade-plugin/maven-metadata.xml (1.6 kB at 16 kB/s)
Downloading from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-shade-plugin/3.6.0/maven-shade-plugin-3.6.0.pom
Downloaded from central: https://repo.maven.apache.org/maven2/org/apache/maven/plugins/maven-shade-plugin/3.6.0/maven-shade-plugin-3.6.0.pom (12 kB at 128 kB/s)
[INFO]
[INFO] The following plugin updates are available:
[INFO]   maven-dependency-plugin ............................ 3.6.1 -> 3.7.0
[INFO]   maven-enforcer-plugin .............................. 3.4.1 -> 3.5.0
[INFO]   maven-javadoc-plugin ............................... 3.6.3 -> 3.7.0
[INFO]   maven-pmd-plugin ................................. 3.22.0 -> 3.23.0
[INFO]   maven-project-info-reports-plugin .................. 3.5.0 -> 3.6.0
[INFO]   maven-shade-plugin ................................. 3.5.3 -> 3.6.0
[INFO]   maven-site-plugin .......................... 4.0.0-M14 -> 4.0.0-M15
[INFO]   maven-surefire-plugin .............................. 3.2.5 -> 3.3.0
[INFO]
[INFO] All plugins have a version specified.
[INFO]
[INFO] Project requires minimum Maven version for build of: 3.8.6
[INFO] Plugins require minimum Maven version of: 3.8.6
[INFO]
[INFO] No plugins require a newer version of Maven than specified by the pom.
[INFO]
[INFO]
[INFO] --- versions-maven-plugin:2.16.2:display-property-updates (default) @ javamavenapp ---
[INFO]
[INFO] The following version properties are referencing the newest available version:
[INFO]   ${codehaus.version.plugin} ................................... 2.16.2
[INFO]   ${jetbrains.annotations.version} ............................. 24.1.0
[INFO]   ${lombok.version} ........................................... 1.18.32
[INFO]   ${maven.clean.plugin} ......................................... 3.3.2
[INFO]   ${maven.compiler.plugin} ..................................... 3.13.0
[INFO]   ${maven.deploy.plugin} ........................................ 3.1.2
[INFO]   ${maven.install.plugin} ....................................... 3.1.2
[INFO]   ${maven.jar.plugin} ........................................... 3.4.1
[INFO]   ${maven.resources.plugin} ..................................... 3.3.1
[INFO]   ${mockito.version} ........................................... 5.12.0
[INFO]   ${native.maven.plugin} ....................................... 0.10.2
[INFO]   ${spotbugs.maven.plugin} .................................... 4.8.5.0
[INFO]   ${spotbugs.version} ........................................... 4.8.5
[INFO] The following version property updates are available:
[INFO]   ${junit.version} ................................ 5.10.2 -> 5.11.0-M2
[INFO]   ${maven.enforcer.plugin} ............................. 3.4.1 -> 3.5.0
[INFO]   ${maven.javadoc.plugin} .............................. 3.6.3 -> 3.7.0
[INFO]   ${maven.pmd.plugin} ................................ 3.22.0 -> 3.23.0
[INFO]   ${maven.project.info.reports.plugin} ................. 3.5.0 -> 3.6.0
[INFO]   ${maven.site.plugin} ......................... 4.0.0-M14 -> 4.0.0-M15
[INFO]   ${maven.surfire.plugin} .............................. 3.2.5 -> 3.3.0
[INFO]
[INFO]
[INFO] --- maven-resources-plugin:3.3.1:resources (default-resources) @ javamavenapp ---
[INFO] Copying 3 resources from src\main\resources to target\classes
[INFO]
[INFO] --- maven-compiler-plugin:3.13.0:compile (default-compile) @ javamavenapp ---
[INFO] Recompiling the module because of changed source code.
[INFO] Compiling 2 source files with javac [debug release 21] to target\classes
[INFO]
[INFO] --- maven-resources-plugin:3.3.1:testResources (default-testResources) @ javamavenapp ---
[INFO] Copying 0 resource from src\test\resources to target\test-classes
[INFO]
[INFO] --- maven-compiler-plugin:3.13.0:testCompile (default-testCompile) @ javamavenapp ---
[INFO] Recompiling the module because of changed dependency.
[INFO]
[INFO] --- maven-surefire-plugin:3.2.5:test (default-test) @ javamavenapp ---
[INFO]
[INFO] --- native-maven-plugin:0.10.2:test (test-native) @ javamavenapp ---
[INFO] Skipped native-image tests since there are no test classes.
[INFO]
[INFO] --- spotbugs-maven-plugin:4.8.5.0:spotbugs (default) @ javamavenapp ---
[INFO] Fork Value is true
[INFO] Done SpotBugs Analysis....
[INFO]
[INFO] --- maven-pmd-plugin:3.22.0:pmd (default) @ javamavenapp ---
[INFO] PMD version: 7.0.0
[INFO] Rendering content with org.apache.maven.skins:maven-default-skin:jar:1.3 skin.
[INFO]
[INFO] --- maven-jar-plugin:3.4.1:jar (default-jar) @ javamavenapp ---
[INFO] Building jar: C:\Projects\Konrad\JavaMavenApp\target\javamavenapp-1.0-SNAPSHOT.jar
[INFO]
[INFO] --- maven-javadoc-plugin:3.6.3:jar (attach-javadocs) @ javamavenapp ---
[INFO] No previous run data found, generating javadoc.
[INFO] Building jar: C:\Projects\Konrad\JavaMavenApp\target\javamavenapp-1.0-SNAPSHOT-javadoc.jar
[INFO]
[INFO] --- native-maven-plugin:0.10.2:compile-no-fork (build-native) @ javamavenapp ---
[INFO] Found GraalVM installation from JAVA_HOME variable.
Downloading from central: https://repo.maven.apache.org/maven2/org/graalvm/buildtools/graalvm-reachability-metadata/0.10.2/graalvm-reachability-metadata-0.10.2-repository.zip
Downloaded from central: https://repo.maven.apache.org/maven2/org/graalvm/buildtools/graalvm-reachability-metadata/0.10.2/graalvm-reachability-metadata-0.10.2-repository.zip (251 kB at 470 kB/s)
[INFO] Downloaded GraalVM reachability metadata repository from file:/C:/Users/a419779/.m2/repository/org/graalvm/buildtools/graalvm-reachability-metadata/0.10.2/graalvm-reachability-metadata-0.10.2-repository.zip
[INFO] Executing: C:\Apps\graalvm-jdk-21.0.3+7.1\bin\native-image.cmd @target\tmp\native-image-16348702461088851478.args de.kneitzel.JavaApp
========================================================================================================================
GraalVM Native Image: Generating 'javamavenapp' (executable)...
========================================================================================================================
For detailed information and explanations on the build output, visit:
https://github.com/oracle/graal/blob/master/docs/reference-manual/native-image/BuildOutput.md
------------------------------------------------------------------------------------------------------------------------
[1/8] Initializing...                                                                                   (19,1s @ 0,15GB)
 Java version: 21.0.3+7-LTS, vendor version: Oracle GraalVM 21.0.3+7.1
 Graal compiler: optimization level: 2, target machine: x86-64-v3, PGO: ML-inferred
 C compiler: cl.exe (microsoft, x64, 19.40.33811)
 Garbage collector: Serial GC (max heap size: 80% of RAM)
 1 user-specific feature(s):
 - com.oracle.svm.thirdparty.gson.GsonFeature
------------------------------------------------------------------------------------------------------------------------
Build resources:
 - 18,00GB of memory (56,7% of 31,76GB system memory, determined at start)
 - 12 thread(s) (100,0% of 12 available processor(s), determined at start)
[2/8] Performing analysis...  [*****]                                                                    (5,2s @ 0,20GB)
    1.958 reachable types   (59,5% of    3.290 total)
    1.808 reachable fields  (44,6% of    4.052 total)
    8.258 reachable methods (35,7% of   23.121 total)
      716 types,    25 fields, and   328 methods registered for reflection
       53 types,    30 fields, and    48 methods registered for JNI access
        1 native library: version
[3/8] Building universe...                                                                               (1,1s @ 0,23GB)
[4/8] Parsing methods...      [*]                                                                        (1,5s @ 0,27GB)
[5/8] Inlining methods...     [***]                                                                      (0,7s @ 0,26GB)
[6/8] Compiling methods...    [****]                                                                    (13,6s @ 0,21GB)
[7/8] Layouting methods...    [*]                                                                        (1,0s @ 0,23GB)
[8/8] Creating image...       [*]                                                                        (1,5s @ 0,24GB)
   2,76MB (46,30%) for code area:     3.680 compilation units
   3,12MB (52,32%) for image heap:   50.799 objects and 43 resources
  84,23kB ( 1,38%) for other data
   5,96MB in total
------------------------------------------------------------------------------------------------------------------------
Top 10 origins of code area:                                Top 10 object types in image heap:
   1,24MB java.base                                          704,63kB byte[] for code metadata
   1,22MB svm.jar (Native Image)                             665,45kB byte[] for java.lang.String
  86,31kB com.oracle.svm.svm_enterprise                      350,02kB java.lang.String
  42,46kB jdk.proxy3                                         307,20kB java.lang.Class
  37,97kB jdk.proxy1                                         208,02kB heap alignment
  30,22kB org.graalvm.nativeimage.base                       153,09kB java.util.HashMap$Node
  29,14kB org.graalvm.collections                            114,01kB char[]
  21,32kB jdk.internal.vm.ci                                  81,42kB java.lang.Object[]
  16,77kB jdk.internal.vm.compiler                            77,23kB byte[] for reflection metadata
  11,90kB jdk.proxy2                                          76,48kB com.oracle.svm.core.hub.DynamicHubCompanion
   2,33kB for 2 more packages                                458,45kB for 504 more object types
                              Use '-H:+BuildReport' to create a report with more details.
------------------------------------------------------------------------------------------------------------------------
Security report:
 - Binary does not include Java deserialization.
 - Use '--enable-sbom' to embed a Software Bill of Materials (SBOM) in the binary.
------------------------------------------------------------------------------------------------------------------------
Recommendations:
 PGO:  Use Profile-Guided Optimizations ('--pgo') for improved throughput.
 INIT: Adopt '--strict-image-heap' to prepare for the next GraalVM release.
 HEAP: Set max heap for improved and more predictable memory usage.
 CPU:  Enable more CPU features with '-march=native' for improved performance.
 QBM:  Use the quick build mode ('-Ob') to speed up builds during development.
------------------------------------------------------------------------------------------------------------------------
                        1,4s (3,1% of total time) in 244 GCs | Peak RSS: 0,77GB | CPU load: 5,17
------------------------------------------------------------------------------------------------------------------------
Produced artifacts:
 C:\Projects\Konrad\JavaMavenApp\target\javamavenapp.exe (executable)
========================================================================================================================
Finished generating 'javamavenapp' in 44,6s.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  01:16 min
[INFO] Finished at: 2024-06-17T09:24:29+02:00
[INFO] ------------------------------------------------------------------------

C:\Projects\Konrad\JavaMavenApp>

Evtl. noch der Hinweis: Der Aufruf von \Apps\GraalVM21:
Der setzt einfach JAVA_HOME und PATH:

@echo off
set JAVA_HOME=C:\Apps\graalvm-jdk-21.0.3+7.1
set PATH=%JAVA_HOME%\bin;%PATH%

Und was halt anders ist: Gewisse Dinge wie der Classloader funktionieren da jetzt so nicht mehr. Daher kann es Probleme geben. Ich hatte z.B. Probleme, das zusammen mit JavaFX zum laufen zu kriegen (Weshalb das Projekt JavaFXMavenProject von mir kein native Profil hat). Ich habe da aber nicht zu viel Zeit investiert aber in der GraalVM Dokumentation finden sich Hinweise, was da prinzipiell zu tun ist. Daher ist das tatsächlich deutlich mehr als einfach nur ein Maven Profil zu kopieren (So man mehr hat als ein "Hello World").

 

[Zrebna]

Hi nochmal!

Also mein erstes Ziel ist erstmal mittels JPackage ein app-image zu erzeugen, das dann auch von meinem hello_world-Programm eine ausführbare Datei (exe) enthält.
Leider stoße ich hierbei auf Probleme, bei denen ich nicht weiter komme.

Erstmal zu meinem Vorgehen:

Mein hello_world Maven-Projekt:

package org.example;

import java.util.Scanner;

public class HelloWorldGenerator {
    public static void main(String[] args) {
        System.out.println("Hello world!");

        // Halte die Konsole geöffnet, bis der Benutzer eine Taste drückt
        System.out.println("Press Enter to exit...");
        Scanner scanner = new Scanner(System.in);
        scanner.nextLine();
    }
}

Die POM samt dem Compiler- und Assembly-PlugIn - diese braucht man meiner Informationen nach, damit das mit JPacke korrekt funktioniert:
PS.: java -version und javac -version ergeben beide die Version 19 des JDKs und des Compilers - also das sollte auch passen.

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://www.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>org.example</groupId>
    <artifactId>hello_world_app</artifactId>
    <version>1.0-SNAPSHOT</version>

    <properties>
        <maven.compiler.source>19</maven.compiler.source>
        <maven.compiler.target>19</maven.compiler.target>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <main.class>org.example.HelloWorldGenerator</main.class>
    </properties>

    <dependencies>
        <!-- Add any dependencies if needed -->
    </dependencies>

    <build>
        <plugins>
            <!-- Compiler Plugin -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.8.1</version>
                <configuration>
                    <source>${maven.compiler.source}</source>
                    <target>${maven.compiler.target}</target>
                </configuration>
            </plugin>

            <!-- Assembly Plugin -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-assembly-plugin</artifactId>
                <version>3.3.0</version>
                <configuration>
                    <archive>
                        <manifest>
                            <mainClass>${main.class}</mainClass>
                        </manifest>
                    </archive>
                    <descriptorRefs>
                        <descriptorRef>jar-with-dependencies</descriptorRef>
                    </descriptorRefs>
                </configuration>
                <executions>
                    <execution>
                        <phase>package</phase>
                        <goals>
                            <goal>single</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</project>

Danach führe ich auf das Projekt ein 'mvn clean package' aus, sodass im target-Ordner folgende zwei Jar-Dateien erzeugt werden:

• hello_world_app-1.0-SNAPSHOT.jar
• hello_world_app-1.0-SNAPSHOT-jar-with-dependencies.jar

Ich habe dann vorab geprüft, ob die jar-Datei ausgeführt werden kann und ob da alles passt, was der Fall zu sein scheint, außer ggf. siehe Kommentar im folgendem Code-Block:

C:\Users\kr-ga\Desktop\Workflow\HelloWorldApp\hello_world_app\target>jar tf hello_world_app-1.0-SNAPSHOT-jar-with-dependencies.jar
META-INF/MANIFEST.MF
META-INF/
org/
org/example/
META-INF/maven/
META-INF/maven/org.example/
META-INF/maven/org.example/hello_world_app/
org/example/HelloWorldGenerator.class
META-INF/maven/org.example/hello_world_app/pom.xml
META-INF/maven/org.example/hello_world_app/pom.properties

C:\Users\kr-ga\Desktop\Workflow\HelloWorldApp\hello_world_app\target>jar xf hello_world_app-1.0-SNAPSHOT-jar-with-dependencies.jar META-INF/MANIFEST.MFtype META-INF/MANIFEST.MF

// hier kam nichts - ich hätte erwartet:
// Main-Class: org.example.HelloWorldGenerator    ?


C:\Users\kr-ga\Desktop\Workflow\HelloWorldApp\hello_world_app\target>java -jar hello_world_app-1.0-SNAPSHOT-jar-with-dependencies.jar
Hello world!
Press Enter to exit...

Nun der Befehl, um das app-image samt der EXE zu erzeugen:

jpackage --input . --dest app-image --name hello --main-jar hello_world_app-1.0-SNAPSHOT-jar-with-dependencies.jar --main-class org.example.HelloWorldGenerator --type app-image --win-console

Hier kam folgender Fehler:

java.io.IOException: Cannot access file with path exceeding 32000 characters

Es wurde ein app-image-Ordner mit Unterordner 'hello' erzeugt, indem auch die EXE und ein run-time-Ordner (mit bin, lib, etc.) liegt.
Dann wirds aber komisch:
Es wurde dann rekursiv bis ins unendliche die Ordner-Struktur 'app -> app-image -> hello' erzeugt.
Außer ganz zu Beginn, wo in dem app-Ordner noch eine cfg-Datei liegt, sind alle anderen Ordner leer und das geht wohl bis ins Unendliche - hier ein Bild zur Veranschaulichung:





Wenn ich in der Prompt die EXE ausführe, kommt:

C:\Users\kr-ga\Desktop\Workflow\HelloWorldApp\hello_world_app\target\app-image\hello>hello.exe
Fehler: Hauptklasse org.example.HelloWorldGenerator konnte nicht gefunden oder geladen werden
Ursache: java.lang.ClassNotFoundException: org.example.HelloWorldGenerator

Beunruhigend ist, dass ich auch weder den app-image-Ordner, noch den gesamten Projekt-Ordner selbst löschen kann:



Ich habe es auch mittels der Windows-Powershell so versucht:

Remove-Item -Path "C:\Users\kr-ga\Desktop\Workflow\HelloWorldApp\hello_world_app\target\app-image" -Recurse -Force

Leider hat das nichts geholfen:

Remove-Item : Ein Teil des Pfades "C:\Users\kr-ga\Desktop\Workflow\HelloWorldApp\hello_world_app\target\ai\h\a\app-imag
e\hello\app\app-image\hello\app\app-image\hello\app\app-image\hello\app\app-image\hello\app\app-image\hello\app\app-ima
ge\hello\app\app-image\hello\app\app-image\hello\app\app-image" konnte nicht gefunden werden.
In Zeile:1 Zeichen:1
+ Remove-Item -Path "C:\Users\kr-ga\Desktop\Workflow\HelloWorldApp\hell ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : WriteError: (C:\Users\kr-ga\...d_app\target\ai:String) [Remove-Item], DirectoryNotFoundE
   xception
    + FullyQualifiedErrorId : RemoveItemIOError,Microsoft.PowerShell.Commands.RemoveItemCommand

Evtl. wird irgendwann mal der Pfad zu lage, was ja kein Wunder ist, wenn rekursive immer weitere Ordner der selben "3er-Hierarchie" wie oben beschrieben, erzeugt werden.

Kann jemand helfen?

 

[KonradN]

Beunruhigend ist, dass ich auch weder den app-image-Ordner, noch den gesamten Projekt-Ordner selbst löschen kann:

Das wird einfach daran liegen, dass ein Prozess noch aktiv ist, der dort etwas geöffnet hat.

Was den Fehler angeht: Du nimmst als Input das aktuelle Verzeichnis und legst Da auch das Resultat ab. Da baut sich dann vermutlich eine rekursive Struktur auf bis eine Pfadlänge erreicht ist, die zu lang ist.

 

[Zrebna]

Das wird einfach daran liegen, dass ein Prozess noch aktiv ist, der dort etwas geöffnet hat.

Ich hab zwischenzeitlich den PC neu gestartet ( spätestens dann müssten ja alle Prozesse abbrechen) und dann den Löschvorgang nochmals vergeblich versucht.
Laut Process Explorer war da ebenfalls kein Prozess mehr offen, der das Löschen verhindern könnte.

Was den Fehler angeht: Du nimmst als Input das aktuelle Verzeichnis und legst Da auch das Resultat ab. Da baut sich dann vermutlich eine rekursive Struktur auf bis eine Pfadlänge erreicht ist, die zu lang ist.

Danke für diesen Tip - ich versuche dann mal morgen das Kommando anzupassen und teste es dann nochmal.

 

[KonradN]

Die Fehlermeldung besagt, dass das Verzeichnis nicht leer ist. Da wäre also dann die Frage, was da drin ist. Einfach mal mit einem Terminal (z.B. der Eingabeaufforderung) in das Verzeichnis gehen und dann ein dir /A ausführen.

Und evtl. mal ein rmdir /S /Q ausführen zum löschen.

Sowas sollte das dann eigentlich löschen. Ansonsten müsste man die Rechte und ggf. das Filesystem prüfen.

 

[DefconDev]

Ich verstehe es auch nicht. Wie kommt man darauf, Desktop-Anwendungen auf Basis von Java zu entwickeln? Java macht nur Sinn in Server- und Cloud-Umgebungen.

Ich denke native Apps für Android, wenn auch Kotlin immer beliebter wird, werden heute noch oft in Java geschrieben.

Sind doch etwas weiter gefasst auch Desktop-Anwendungen

Und JavaFX für "richtige" Desktop-Anwendungen sehe ich zumindest im Opensource als tauglich an.

 

[KonradN]

Also das Thema ist aus meiner Sicht Off-Topic, aber wenn das die Leute doch noch so sehr beschäftigt, dann teile ich auch einmal meine Sichtweise:

Es ist doch bei allen Projekten unter dem Strich das Gleiche:

• Was sind die Anforderungen und Rahmenbedingungen?
• Was für Ressourcen sind vorhanden?

Thema Anforderungen und Rahmenbedingungen können sein:

• Eine minimale GUI reicht aus. Also muss nichts modernes, schönes sein.
• Sicherheitsanforderungen so dass Abhängigkeiten durchaus hohe Kosten haben können.
• Evtl. vorhandener Code / Libraries

Ressourcen betrifft so Dinge wie:
- Was für Leute habe ich und was für ein KnowHow haben diese?

Malen wir dies einfach etwas aus:

• Wenn ich ein Java Entwicklungsteam habe und dieses ist "frei" für eine schnelle Entwicklung: Warum sollen die dann nicht mit Java eben die Desktop Anwendung bauen?
• Wenn ich bereits im "Server Projekt" Libraries habe, dessen Funktionalität ich brauche: Wieso die nicht in der Desktop Anwendung nutzen?
• Wenn ich in einem kritischen Umfeld bin und alle Abhängigkeiten genau geprüft werden: Will ich dann neue Abhängigkeiten wie QT oder sonst irgendwas einbringen? Swing habe ich im JDK bereits dabei und ich brauche nichts neues mehr. (Ja, eine Risikobewertung muss halt sein und dann muss das auch in ein Monitoring rein, damit auf Lücken und so schnell reagiert werden kann. Und selbst wenn man das locker nimmt: Unter dem Strich muss es mit Version auf einer Liste von eingesetzten Produkten landen oder so ...)

Das nur einmal etwas aus der Praxis. Wir haben halt auch ein paar Desktop Anwendungen. Und die sind mal eben schnell in Java entstanden. Und die greifen teilweise auf Libraries aus dem Hauptprojekt zu. Und auf den Zielsystemen läuft es direkt, denn Java ist halt vorhanden ...

Und das ist eigentlich etwas, das bei einem Projekt doch auf der Hand liegt und ich bin bisher davon ausgegangen, dass erfahrende Projektleute das eigentlich massiv kennen sollten. Das ändert nichts daran, dass ich auch gewisse Dinge als "totes Pferd" bezeichnen würde (Swing, JavaFX, ...), aber so lange das tote Pferd gewisse Aufgaben noch erledigen kann: Warum nicht?

Und ja - das Thema des Threads ist mit das Thema, das einem doch deutlich vor Augen führt, dass dies ein Bereich ist, der total vernachlässigt wird. Die Nische wird einfach nicht bedient und sich Details von swing oder javafx anzusehen ist eher Zeitverschwendung (So man es nicht halt doch direkt braucht für ein Projekt. Es ist nichts, das auf einem CV Sinn macht würde ich sagen).

Aber damit genug zu dem Off Topic Thema.

 

[Zrebna]

Sry, Doppelpost

 

[Zrebna]

Die Fehlermeldung besagt, dass das Verzeichnis nicht leer ist. Da wäre also dann die Frage, was da drin ist. Einfach mal mit einem Terminal (z.B. der Eingabeaufforderung) in das Verzeichnis gehen und dann ein dir /A ausführen.

Und evtl. mal ein rmdir /S /Q ausführen zum löschen.

Sowas sollte das dann eigentlich löschen. Ansonsten müsste man die Rechte und ggf. das Filesystem prüfen.

Wie geschrieben, das Unterverzeichnis X wird ja nie leer sein, weil es immer noch ein Unterverzeichnis X+1 geben wir - er hat ja diese oben beschriebene Ordnerstruktur rekursiv (?) bis uns Unendliche getrieben - da gibt es kein Halt - scheinbar, sondern eine unendliche Kette von leeren Ordnern...

 

[KonradN]

rmdir will natürlich noch den Namen des Ordners, das hatte ich auf die Schnelle vergessen mit anzugeben ... also bei dir dann wohl rmdir /S /Q hello

 

[Zrebna]

rmdir will natürlich noch den Namen des Ordners, das hatte ich auf die Schnelle vergessen mit anzugeben ... also bei dir dann wohl rmdir /S /Q hello

Ah ok, danke.

Leider hat auch das nicht geklappt - gesagt wird eben, dass das Verzeichnis nicht leer ist - ja stimmt, da ist dann ein Ordner 'app' drin, dort wiederum ein Ordner 'app-iamge' und dort wieder ein 'hello'-Ordner - dies geschieht bis ins Unendliche.

 

[Zrebna]

Ah ok, danke.

Leider hat auch das nicht geklappt - gesagt wird eben, dass das Verzeichnis nicht leer ist - ja stimmt, da ist dann ein Ordner 'app' drin, dort wiederum ein Ordner 'app-iamge' und dort wieder ein 'hello'-Ordner - dies geschieht bis ins Unendliche.

Update:
Zumindest bin ich nun in der Lage ein korrektes app-image zu erzeugen, ohne dass unendlich viele Ordner erzeugt werden.

Ich habe dafür gem. deinem Input weiter oben das Kommando so angepasst:

jpackage --input input --dest app-image --name hello2 --main-jar hello2-1.0-SNAPSHOT-jar-with-dependencies.jar --main-class org.example.Main --type app-image --win-console

Was ich vorab gemacht habe ist, dass ich einen Input-Ordner erstellt habe und dort die Jar hineinkopiert habe, sodass das Eingabe- und Ausgabeverzeichnis nicht mehr das selbe Verzeichnis verwenden.
Ist dieses Vorgehen so Konvention bzw. Standard? Gibt es betimmte Naming-Konventionen wie man das Input-Verzeichnis in diesem use case nennen sollte?

Bzgl. dem Löschen der alten Versuche bin ich noch nicht am Ziel xD

 

[KonradN]

Ok, es kann sein, dass das rmdir sogar noch ein Limit von 260 Zeichen beim Pfad hat so dass ab einer Tiefe nicht weiter gelöscht werden kann ...

Also versuchen wir noch die Powershell Methode. Einfach mal Powershell öffnen und da dann ausführen:
Remove-Item -LiteralPath "\\?\C:\path\to\problematic\folder" -Force -Recurse
Den Pfad natürlich anpassen zu dem Pfad, der gelöscht werden soll. Das \\? davor sollte aber bleiben!

Prinzipiell kann es auch interessant sein, einmal die Registry zu prüfen:
Ist in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem ein Schlüssel LongPathsEnabled? Der auf 1 steht?
Ich bin über einen Beitrag gestolpert, dass man damit lange Pfade bis zu 32767 Zeichen für viele Programme aktivieren kann. Den Schlüssel zu setzen (und dann den Rechner neu zu starten) könnte Dich also in die Lage versetzen, das Verzeichnis auch mit dem Windows Explorer zu löschen oder so ...

 

[Dukel]

Das \\?\ sollte auch mit rmdir gehen.

Das 260 Zeichen Limit im Pfad ist nicht im NTFS enthalten sondern in der API, die Windows noch nutzt (Explorer, CMD, Powershell). Mit \\?\ wird die andere API forciert.

 

[Hobbes]

Das 260 Zeichen Limit im Pfad ist nicht im NTFS enthalten sondern in der API, die Windows noch nutzt (Explorer, CMD, Powershell). Mit \\?\ wird die andere API forciert.

Ernsthaft? rofl Windows war, ist und bleibt einfach ein grottiges Kack-System.

 

[Dukel]

Das ist der Nachteil an der Abwärtskompatibilität. Manche Dinge werden halt ewig, andere nicht so wenig mitgenommen.

Maximum Path Length Limitation - Win32 apps

Starting in Windows 10, version 1607, MAX_PATH limitations have been removed from many common Win32 file and directory functions. However, your app must opt-in to support the new behavior.

learn.microsoft.com

 

[Hobbes]

Ich habe für die weitere Windows-Diskussion mal einen neuen Thread gestartet

https://www.java-forum.org/thema/windows-das-mysterium.204489/

 

[Zrebna]

Ok, es kann sein, dass das rmdir sogar noch ein Limit von 260 Zeichen beim Pfad hat so dass ab einer Tiefe nicht weiter gelöscht werden kann ...

Also versuchen wir noch die Powershell Methode. Einfach mal Powershell öffnen und da dann ausführen:
Remove-Item -LiteralPath "\\?\C:\path\to\problematic\folder" -Force -Recurse
Den Pfad natürlich anpassen zu dem Pfad, der gelöscht werden soll. Das \\? davor sollte aber bleiben!

Prinzipiell kann es auch interessant sein, einmal die Registry zu prüfen:
Ist in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem ein Schlüssel LongPathsEnabled? Der auf 1 steht?
Ich bin über einen Beitrag gestolpert, dass man damit lange Pfade bis zu 32767 Zeichen für viele Programme aktivieren kann. Den Schlüssel zu setzen (und dann den Rechner neu zu starten) könnte Dich also in die Lage versetzen, das Verzeichnis auch mit dem Windows Explorer zu löschen oder so ...

LongPathsEnabled wäre bei mir auf 0 gesetzt - setzt man ihn auf 1 könnte man evtl. lange Pfade aktivieren.
Ich kann es leider nicht mehr testen, weil das Löschen nun dank eurer Hilfe geklappt hat

rm -r \\?\C:\Users\kr-ga\Desktop\Workflow\HelloWorldApp\hello\target\app-image

Hätte bestimmt auch mit deinem Befehl geklappt, weil die Crux ja ist mittels der Verwendung von '\\?' das 260 Längen-Limit von Windows zu umgehen, was es wohl gibt... Jedoch den habe ich diesen Befehl abgebrochen, weil es lange gedauert hat und ich fälschlicherweise angenommen habe, dass der Löschvorgang 'stuck' ist und nicht klappen wird.
Bei dem obigen Befehl hat es auch eine Weile gedauert - aber nun hat es endlich geklappt.

Danke nochmal für den Support

 

[Zrebna]

Hi,

es folgt ein Update zu meiner Zielsetzung:
Aus einer simplem hello-world-Maven-Programm eine ausführbare Datei zu erzeugen und hier JPacke zu verwenden war nur Vorlauf.
Wie Konrad bereits erklärt hat, erzeugt man mit diesem Approach ein image samt EXE, aber leider auch samt benötigtem JRE -> zu groß!

Nach Absprache möchte ich es nun doch mit GraalVM versuchen.

Ich habe mir dazu

• GraalVM Version 21 installiert - also die selbe Version wie Konrad in seinem Projekt.
• VisualStudio 22 installiert.

Innerhalb der Visual Studio Developer Command Prompt setze ich dann temporär die Systemveriable und den Path auf GraalVM

set JAVA_HOME=C:\Program Files\graalvm-jdk-21.0.3+7.1
set PATH=%JAVA_HOME%\bin;%PATH%

Die Version ist dann korrekt und das habe ich mittels java --version und javac --version überprüft.

Danach navigiere ich schon zum Projektordner und ich setze den Befehl:

mvn -Pnative clean package

Folgender Error-Trace:

C:\Users\kr-ga\Desktop\Workflow\HelloWorldApp\hello_world_app>mvn -Pnative clean package
[INFO] Scanning for projects...
[INFO]
[INFO] --------------------< org.example:hello_world_app >---------------------
[INFO] Building hello_world_app 1.0-SNAPSHOT
[INFO]   from pom.xml
[INFO] --------------------------------[ jar ]---------------------------------
[INFO]
[INFO] --- clean:3.2.0:clean (default-clean) @ hello_world_app ---
[INFO] Deleting C:\Users\kr-ga\Desktop\Workflow\HelloWorldApp\hello_world_app\target
[INFO]
[INFO] --- resources:3.3.1:resources (default-resources) @ hello_world_app ---
[INFO] Copying 0 resource from src\main\resources to target\classes
[INFO]
[INFO] --- compiler:3.8.1:compile (default-compile) @ hello_world_app ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 1 source file to C:\Users\kr-ga\Desktop\Workflow\HelloWorldApp\hello_world_app\target\classes
[INFO]
[INFO] --- resources:3.3.1:testResources (default-testResources) @ hello_world_app ---
[INFO] skip non existing resourceDirectory C:\Users\kr-ga\Desktop\Workflow\HelloWorldApp\hello_world_app\src\test\resources
[INFO]
[INFO] --- compiler:3.8.1:testCompile (default-testCompile) @ hello_world_app ---
[INFO] Changes detected - recompiling the module!
[INFO]
[INFO] --- surefire:3.2.5:test (default-test) @ hello_world_app ---
[INFO]
[INFO] --- jar:3.4.1:jar (default-jar) @ hello_world_app ---
[INFO] Building jar: C:\Users\kr-ga\Desktop\Workflow\HelloWorldApp\hello_world_app\target\hello_world_app-1.0-SNAPSHOT.jar
[INFO]
[INFO] --- native:0.9.20:compile-no-fork (build-native) @ hello_world_app ---
[INFO] Found GraalVM installation from JAVA_HOME variable.
[INFO] Executing: C:\Program Files\graalvm-jdk-21.0.3+7.1\bin\native-image.cmd @target\tmp\native-image-961721902608646454.args
Warning: The option '-H:Path=C:\\Users\\kr-ga\\Desktop\\Workflow\\HelloWorldApp\\hello_world_app\\target' is experimental and must be enabled via '-H:+UnlockExperimentalVMOptions' in the future.
Warning: The option '-H:Name=hello_world_app' is experimental and must be enabled via '-H:+UnlockExperimentalVMOptions' in the future.
Warning: Please re-evaluate whether any experimental option is required, and either remove or unlock it. The build output lists all active experimental options, including where they come from and possible alternatives. If you think an experimental option should be considered as stable, please file an issue.
========================================================================================================================
GraalVM Native Image: Generating 'hello_world_app' (executable)...
========================================================================================================================
For detailed information and explanations on the build output, visit:
https://github.com/oracle/graal/blob/master/docs/reference-manual/native-image/BuildOutput.md
------------------------------------------------------------------------------------------------------------------------

[1/8] Initializing...                                                                                    (0,0s @ 0,05GB)
Error: Unable to detect supported WINDOWS native software development toolchain.
Querying with command ''C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.40.33807\bin\HostX86\x86\cl.exe' /EP 'C:\Users\kr-ga\AppData\Local\Temp\SVM-8015519429080927370\detect-cl-version-info.c'' prints:
  Microsoft (R) C/C++-Optimierungscompiler Version 19.40.33811 f?r x86
  Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten.

  detect-cl-version-info.c

  M_X64=_M_X64
  M_ARM64EC=_M_ARM64EC
  MSC_FULL_VER=194033811
Error: To prevent native-toolchain checking provide command-line option -H:-CheckToolchain
------------------------------------------------------------------------------------------------------------------------
                        0,3s (6,2% of total time) in 16 GCs | Peak RSS: 0,38GB | CPU load: 2,65
========================================================================================================================
Finished generating 'hello_world_app' in 3,9s.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  9.078 s
[INFO] Finished at: 2024-06-21T14:39:36+02:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.graalvm.buildtools:native-maven-plugin:0.9.20:compile-no-fork (build-native) on project hello_world_app: Execution of C:\Program Files\graalvm-jdk-21.0.3+7.1\bin\native-image.cmd @target\tmp\native-image-961721902608646454.args returned non-zero result -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException

Kann nochmal Jemand helfen?

 

[Zrebna]

Edit zum obigem Post:

Hier noch die Auswahl, die ich beim Installieren von VS getroffen habe:

 

[KonradN]

Auf den ersten Blick würde ich auf Grund der Fehlermeldung
Error: Unable to detect supported WINDOWS native software development toolchain.
vermuten, dass Du einfach eine normale Eingabeaufforderung verwendet hast und nicht ein Command Prompt mit allen Native Tools von Visual Studio.

Bei der Installation solltest Du auch einen Link im Startmenü haben: "x64 Native Tools Command Prompt for Visual Studio 2022" (oder so ähnlich).

Visual Studio installiert in der Regel einiges mehr - halt auch Toolchains für ARM64 und so. Daher hast Du nach der Installation nicht alles automatisch in den Pfaden konfiguriert (Denn was für eine Toolchain willst Du nutzen? x86? x64? Oder ARM64?)

Daher ist es wichtig, die richtige Toolchain zu konfigurieren. Das kannst Du einfach über ein entsprechenden Command Prompt machen.

 

[Zrebna]

Auf den ersten Blick würde ich auf Grund der Fehlermeldung
Error: Unable to detect supported WINDOWS native software development toolchain.
vermuten, dass Du einfach eine normale Eingabeaufforderung verwendet hast und nicht ein Command Prompt mit allen Native Tools von Visual Studio.

Bei der Installation solltest Du auch einen Link im Startmenü haben: "x64 Native Tools Command Prompt for Visual Studio 2022" (oder so ähnlich).

Visual Studio installiert in der Regel einiges mehr - halt auch Toolchains für ARM64 und so. Daher hast Du nach der Installation nicht alles automatisch in den Pfaden konfiguriert (Denn was für eine Toolchain willst Du nutzen? x86? x64? Oder ARM64?)

Daher ist es wichtig, die richtige Toolchain zu konfigurieren. Das kannst Du einfach über ein entsprechenden Command Prompt machen.

Konrad du verdienst einen Orden

Bei mir im Startmenu war nur diese VS-related Promt zu sehen:
"Developer Command Prompt for VS 2022"

Daher gestern 2 Stunden lang mit der falschen Prompt Versuche gestartet xD
Nun hat es endlich geklappt - Danke!

Aus Verzweiflung habe ich gestern auch in meiner IDE (Intellij) das JDK auf das temporär gesetzte "graalvm-jdk-21.0.3+7.1"-JDK gesetzt - ist/war das überhaupt notwendig?
Edit: Habe es gerade getestet - und an der IDE muss man wohl nichts ändern - kannst du das so bestätigen?


Ansonsten habe ich nun eine ausführbare Exe-Datei:





Diese ist nun gerade mal ca. 13 MB groß, was ein erheblicher Vorteil gegenüber der Methode mit JPacke ist - hier war das app-iamge, das man ja mitausliefern müsste, incl. der dortigen EXE ca. 125 MB groß.

Die EXE kann ich wohl nun einfach z.B. an einen Kumpel senden und er kann sie dann wohl ohne weiteres bei sich auf dem Rechner ausführen, sofern er Windows verwendet.

Wenn die EXE aber auf einem Linux-System laufen muss, dann ist wohl die empfohlene Vorgehensweise, ein natives Image für Linux zu erstellen.
Ist folgender Ansatz korrekt?

• Java-Projekt auf Linux-System kopieren.
• Auf Linux muss nun ebenfalls GraalVM installiert werden aber wohl nicht Visual Studio, was ein Vorteil wäre. Dort setzt man die Befehle wohl im normalem Linux Terminal und braucht nicht die VS-Prompt.
• Nun ebenfalls in der korrekten VS-Prompt temporär das SDK auf die GraalVM setzen und den Befehl abfeuern, der das native Image erzeugt:

export JAVA_HOME=/usr/lib/jvm/graalvm-ce-java21-21.0.3
export PATH=$JAVA_HOME/bin:$PATH
mvn -Pnative clean package

Ist das soweit korrekt?

Falls ja, ist das die gängige Art und Weise oder gibt es "bessere"/gängigere Art und Weisen?

Gelesen habe ich noch, dass man den Ansatz 'Cross Kompilierung' nutzen kann, bei dem man das native Image, also die ausführbare Datei, innerhalb eines Docker-Containers erstellen kann - jedoch eine ausführbare Datei für Linux, also keine exe-Datei, da diese Windows-spezifisch sind.
Das kann man alles auf seinem Windows-Rechner erledigen - am Ende kann man das für Linux erstellte native Image aus dem Container extrahieren und auf das Linux-Zielsystem übertragen und dort dann ausführen.

Welcher Ansatz ist gängiger?

 

[Marinek]

Gelesen habe ich noch, dass man den Ansatz 'Cross Kompilierung' nutzen kann, bei dem man das native Image, also die ausführbare Datei, innerhalb eines Docker-Containers erstellen kann - jedoch eine ausführbare Datei für Linux, also keine exe-Datei, da diese Windows-spezifisch sind.
Das kann man alles auf seinem Windows-Rechner erledigen - am Ende kann man das für Linux erstellte native Image aus dem Container extrahieren und auf das Linux-Zielsystem übertragen und dort dann ausführen.

Welcher Ansatz ist gängiger?

Deutlich gängiger ist es eine Java Anwendung einfach in einer Java VM laufen zu lassen. Diese kann dann auch innerhalb eines Containers sein und dann auf Windows oder Linux ist egal...

Es sei denn du willst Docker auf Linux laufen lassen.

Sonst habe ich nicht verstanden, was du hier machen willst...

 

[KonradN]

Also wenn Du es für andere Betriebssysteme haben willst, dann musst Du es auf dem entsprechenden Betriebssystem bauen. Dazu brauchst Du dann die entsprechenden Build Tools. Unter macos wäre es xcode und unter Linux halt das übliche GNU c++ Zeug. Sollte aber alles auch bei GraalVM dokumentiert sein, was Du brauchst.

Was das dann genau für ein System ist, ist egal. Du kannst einen physischen Rechner verwenden (Also z.B. einen PC nehmen mit Linux) oder es kann virtuell laufen.

Auf einem Windows 10 oder 11 System ist oft WSL mit das einfachste. Dann hast Du eine Linux VM, die sehr gut integriert ist. Da hast Du dann auch ein X11, also die Möglichkeit, einfach grafische Programme auszuführen oder direkten Zugriff auf das Dateisystem.

Prinzipiell kann es aber auch einfach ein Docker Image sein. Du kannst Dir z.B. ein Ubuntu Image ziehen und dann alles installieren, das Du brauchst. Das ist aber dann in der Regel einiges, da die Images relativ "minimal" sind. Aber das habe ich auch schon gemacht und das funktioniert gut (man sollte aber wissen, was man macht).

Wenn man generell ein Produkt für diverse Systeme bauen möchte (also regelmäßig), dann wäre generell zu überlegen, da bei einer ci/cd Pipeline mit entsprechenden Workern das zu automatisieren. Und da kann man ggf. schauen, ob man sowas selbst aufbauen muss oder ob es da nicht bereits entsprechende Lösungen gibt, so dass man lediglich vorhandene Worker einbinden muss.