Produziert das Tool "jpackage" (ab JDK 14) .exe Dateien, die auf einer Zielumgebung ohne JRE lauffähig sind ?`

[osix]

Ich werde bald auf JDK 14 (oder 15) umsteigen.

Kann ich dann in Zukunft mit dem Tool "jpackage" exe-Dateien (oder msi-Dateien in Window) erstellen, die dann auf einer Zielumgebung lauffähig sind, ohne das ein JRE installiert sein muß ?

Geht das auch, wenn ich Libraries verwende, wie z.B. Apache POI zum Auslesen von Excel-Dateien ?

Was ist dann der Unterschied zu "jlink" ? Das gibt es wie ich hörte seit JDK 11 (aber auch das kann ich nicht testen, weil ich noch auf JDK 8 bin)

Vielen Dank für eure Antworten !

 

[mrBrown]

Ich werde bald auf JDK 14 (oder 15) umsteigen.

Je nachdem wann "bald" ist, solltest du vielleicht sogar direkt 16 nehmen 😉

Kann ich dann in Zukunft mit dem Tool "jpackage" exe-Dateien (oder msi-Dateien in Window) erstellen, die dann auf einer Zielumgebung lauffähig sind, ohne das ein JRE installiert sein muß ?

Ja.

Geht das auch, wenn ich Libraries verwende, wie z.B. Apache POI zum Auslesen von Excel-Dateien ?

Ja.

Was ist dann der Unterschied zu "jlink" ? Das gibt es wie ich hörte seit JDK 11 (aber auch das kann ich nicht testen, weil ich noch auf JDK 8 bin)

JLink baut die jeweilige Laufzeitumgebung, im wesentlichen die Kombination aus JRE und Dependencies.

Jpackage baut dann daraus eine exe/msi/app/pki/whatever. Jackage ist quasi das schöne Verpacken dessen, was JLink produziert hat 🙂

 

[osix]

Das ist ja SUPERPRIMA !
das heißt das ganze Geraffel, das man bisher hatte, mit "(Holy)? Grahl" und andere Tools um eine exekutierbare Datei ohne JRE installiert zu haben, entfällt ? (Zum Glück hab ich mich da noch nicht eingearbeitet....)

Warum gibt es das erst jetzt, und nicht gleich schon seit Java 2 ?

Oder muß Oracle dringend nachlegen, um sich gegen "die Schlange" zu behaupten ?

 

[LimDul]

Grundsätzlich musst du dafür Oracle fragen 🙂

Was ich mir aber vorstellen kann, was dazu beigetragen hat:

Bis Java 8 waren die Release-Zyklen von Java sehr sehr lang. Das heißt, es gab eigentlich immer mur ein relevantes JRE, was irgendwer 1x installieren musste und damit war alles lauffähig. Der Bedarf war daher nicht so hoch, native Anwendung zu bauen.

Zudem "verliert" man mit so Sachen wie jpackage einen Teil der Plattformunabhängigkeit, den Java immer als Vorteil vor sich her trägt. Das nämlich eine Anwendung (=JAR-File) auf allen Plattformen lauffähig ist. Mit diesen Tools baut man für jede Plattform eigene Binaries, die zudem größer sind.

Weiterhin war/ist Java hauptsächlich im Bereich Backend-Anwendung, Enterprise Anwendungen stark. Da reden wir eh über gemanagte Umgebungen, wo die Installation des passenden JDKs/JREs kein größeres Problem ist. Das verpacken in Native Anwendungen hat den Fokus eher auf den "normalen" Endanwender, aber da hatte Java nicht so den Fokus drauf.

Das alles + die Frage wie sehr Oracle Java unterstützt oder nur als Anhängsel mal eingekauft hat - dürfte stark dazu beigetragen haben, dass so ein Tool nicht die höchste Priorität hatte.

 

[kneitzel]

Also generell ist das entscheidende mit Java 9 gekommen: JLink.

Da wird davon Abstand genommen, dass auf dem System ein Java installiert sein muss (Und ist wohl auch der Grund, warum Oracle kein JRE mehr anbietet für Java 9+).

JLink baut ein sogenanntes Image, das einfach nur eine Verzeichnisstruktur ist, welches u.a. auch ein JRE (teilweise) enthält. Gestartet wird hier die Applikation über ein Script (Incl. all der Unzulänglichkeiten wie z.B. unter Windows ein Fenster, das aufgeht oder unter mac os Security Probleme, weil das Script dann plötzlich Zugriff auf weitere Dateien braucht, die z.B. im User-Ordner liegen könnten ....)

jpackage ist nun ein Einpacken dieser Dateien. Das kann neben einem reinen Installer (msi, rpm, deb, pkg, ...) auch ein sogenannte native Image sein. Das Startscript entfällt und es gibt dann eine Applikation zum starten. Also eine exe unter Windows oder ein .app Ordner unter mac os.

Das sind aber keine native Applikationen! Das sind weiterhin ein (Teil) JRE, das eine VM ausführt und die Klassen lädt.

Die native Übersetzung gibt es aber auch. Da wäre dann vor allem GraalVM zu nennen. Dieses nutzt dann die Tools der Umgebung, um eine native Applikation zu bekommen. Also da wird dann wirklich z.B. mit Visual Studio eine reine exe compiliert. Oder auf Mac mit xcode und unter Linux mit den dort üblichen development essentials (gcc und co)...

 

[LimDul]

Ach, was vielleicht auch dazu geführt hat, dass so ein Tool gekommen ist - der zunehmende Container-Wahn (Docker und Co.). Der Fokus - auch im Bereich Enterprise Anwendungen geht vermehrt dahin, nicht auf einem Server X-Anwendungen zu deployen, sondern jeder Anwendung einen - möglichst leichtgewichtigen - Container zur Verfügung zu stellen. Das heißt, man installiert das JRE da dann eh nicht auf Server Ebene, sondern packt es mit in den Container rein, so dass eh jede Anwendung in ihrem Container ihr exklusives JRE hat. Da ist dann der Schritt nicht weit, wenn man eh eine 1 zu 1 Beziehung zwischen Anwendung und JRE hat, dass Problem nicht auf Container-Ebene, sondern auf Anwendungs-Ebene zu lösen.

Die IT Welt ist halt in ständigen Wandel und die Anforderungen, Wünsche und Rahmenbedingungen ändern sich. Früher hätte man Leute für bekloppt erklärt, wenn man für jede 2 MB Java Anwendung ein 100 MB JRE mit dazupackt (Was das an Speicherplatz verbraucht....). Mittlerweile ist das egal.

 

[osix]

oder doch der Kampf gegen die "Schlange" (damit meine ich phython)

Danke für eure ausführlichen Erklärungen, ist interessant !

 

[mrBrown]

oder doch der Kampf gegen die "Schlange" (damit meine ich phython)

Java und Python sind bei Desktop-Anwendungen nicht so sehr direkte Konkurrenten, die besetzen eher beide ihre eigenen "Nischen".

Grund ist eher der schnellere Release-Zyklus, der grundsätzliche Trend zu Containerisierung und der Weggang vom JRE für Endandwender.

Das Äquivalent zu jpackager (=javapackager) gab es schon seit längerem für JavaFX, mit dem Herauslösen von JavaFX aus dem Oracle JDK und auch grundsätzlich machte da eine Generalisierung schon Sinn.