BestPractise für Deployment unter Windows gesucht

[Udo_von_ESA]

Auf meinem Entwicklungsrechner möchte ich eine Anwendung schreiben und diese dann auf dem Produktiv-Rechner laufen lassen. In WWW habe ich nun folgendes Vorgehen gefunden:

• Entwicklungsrechner: installiere aktuelle JDK und ezeuge *.jar
• Produktiv-Rechner: installiere aktuelle JRE und starte *.jar

Leider klappt das nicht. Der Produktiv-Rechner zeigt eine Fehlermeldung weil die JRE mit Version 8 eine kleinere Version hat als das JDK mit Version 15!
Die aktuellen Versionen sind:

• Java Development Kit (JDK): "Java SE 15.0.1" (Quelle: www.oracle.com)
• Java Runtime Environment (JRE): "jre-8u271-windows-x64.exe" (Quelle: www.java.com)

Vermutlich gehe ich also den falschen Weg.
Welches Vorgehen ist hier aktuell "Best Practise" zum Deployment unter Windows?

 

[temi]

Installiere halt einfach die JRE in der richtigen Version oder entwickle mit Version 8, du hast ja den Grund für den Fehlschlag genannt.

Du solltest auch überlegen auf ein freies JDK, z.B. OpenJDK zu wechseln. Bei Oracle haben sich diesbezüglich die Lizenzbedingungen geändert.

Außerdem sollest du in Betracht ziehen eine LTS (Long Time Support) Version von Java zu verwenden. Die aktuelle ist 11.

 

[thecain]

Außerdem sollest du in Betracht ziehen eine LTS (Long Time Support) Version von Java zu verwenden. Die aktuelle ist 11.

Warum? Ich lese die Empfehlung öfters, aber Sinn macht es mMn nur, wenn man den kommerziellen Support auch nutzt. Das tun die Wenigsten, dann sehe ich keinen Vorteil darin, auf die aktuellsten Features zu verzichten.

 

[temi]

Warum? Ich lese die Empfehlung öfters, aber Sinn macht es mMn nur, wenn man den kommerziellen Support auch nutzt. Das tun die Wenigsten, dann sehe ich keinen Vorteil darin, auf die aktuellsten Features zu verzichten.

Weil sonst der "Kunde" gezwungen ist immer auf die aktuelleste JRE zu wechseln und das für Features, die vermutlich gar nicht genutzt werden. Das ist für mich der Sinn von LTE-Versionen (auch mein Linux hier). Ich möchte nicht ständig auf eine neue Version upgraden müssen, aber trotzdem noch Sicherheitsupdates und Fehlerbehebung erhalten (Wobei: gilt das auch für Java? Weiß ich nicht, vielleicht kann ein Wissender was dazu sagen).

Im Firmenumfeld ist es dem User u. U. gar nicht möglich hier ein Upgrade durchzuführen, weil er gar nicht die entsprechenden Berechtigungen besitzt.

Siehe auch das Beispiel des TE. Sein "Kunde" hat Java 8, er entwickelt mit Java 15.

Aber wie ich geschrieben habe, "er sollte es in Betracht ziehen". Das bedeutet ja nicht, dass er es auch tun muss. Man kann drüber nachdenken.

 

[LimDul]

Warum? Ich lese die Empfehlung öfters, aber Sinn macht es mMn nur, wenn man den kommerziellen Support auch nutzt. Das tun die Wenigsten, dann sehe ich keinen Vorteil darin, auf die aktuellsten Features zu verzichten.

Nein, sinnvoll ist es auch, wenn man keine Kontrolle über die Zielumgebung hat. Die aktuellsten Versionen sollte man nur nutzen, wenn man
* Entweder vorgeben kann, welche Java Version auf den Zielsystem installiert sein muss
* Oder die Umgebung direkt mit ausliefert (quasi das JRE mit ausliefert)

Ansonsten sollte man - insbesondere im Unternehmensumfeld - immer auf die LTS Versionen setzen. Beispiel aus der Praxis, wir haben ein Modellierungstool (als Eclipse-Plugin), mit einer Java-Runtime die die erzeugten XMLs interpretiert sowie darauf aufbauend ein paar Enterprise Anwendungen. Aktuelle Voraussetzungen:
* Modellierungstool: Java 8
* Enterprise Anwendungen: Java 8
* Runtime: Java 6

Ab Mitte 2021 wird sich das ändern zu:
* Modellierungstool: Java 11
* Enterprise Anwendungen: Java 11
* Runtime: Java 8

Es ist utopisch da auf was neueres zu gehen, weil das installieren Unternehmen nicht. Deswegen wird die Runtime auch nur (immerhin endlich - ca. 200 Sonar Warnings weniger hier im Projekt) auf Java 8 angehoben - weil selbst Java 11 für manche Kunden zu neu ist.

 

[kneitzel]

Der wichtige Punkt sind aus meiner Sicht Security Updates. Java hatte in der Vergangenheit öfter das eine oder andere Security Issue.

Das spielt natürlich keine Rolle, wenn das eh nicht beachtet wird. Wenn ich weiß, dass der Kunde heute ein JRE oder JDK installiert und dann nur mehr aktualisiert, dann macht es keinen Unterschied.

bezüglich des Deployments möchte ich aber noch sagen, dass Iracle das JRE wohl nicht mehr anbietet, weil es nicht mehr notwendig ist:
Es gibt ab 11 JLink. Du erstellst damit ein Image, das alle Dateien enthält und das der Kunde dann bekommen kann.
Ab 14 gibt es dann noch JPackage um einen Installer zu bauen oder ein Native Image (das Image ist eine Verzeichnisstruktur, die neben Startscript auch JRE und so enthält.

Und spätestens dann ist der Punkt Security Updates hinfällig da die nur zu bekommen wären, wenn eine neue Version ausgeliefert werden soll ...

Daher kann ich @thecain gut verstehen und es spricht nichts gegen die aktuelle Version für einzelne Entwickler. LTS sehe ich eher bei großen Firmen wobei es da auch nicht wirklich Sinn macht. Der Gedanke ist, dass man nicht weiß wann ein Update gefordert wird von einem alten Projekt. Aber die IDEs, die ich kenne, können mit mehreren JDKs umgehen.

Aber in Sache Deployment: JLink und JPackage ansehen! JLink ist einfach in Gradle und Maven zu integrieren ... Installer kann dann mit JPackage oder WIX gebaut werden ... Das wäre das Vorgehen, das ich wählen würde um den Support zu vereinfachen ...

 

[thecain]

* Oder die Umgebung direkt mit ausliefert (quasi das JRE mit ausliefert)

Genau auf das wollte ich hinaus... Mit den von @kneitzel auch schon erwähnten Tools, kann man ohne Probleme ein massgenschneidertes JRE direkt mitausliefern.

Sich auf ein installiertes JRE zu verlassen ist schwierig, sobald man sich nicht mehr in einem gemangten Umfeld mehr befindet. Und in diesen Umfeldern ist es dann auch nicht mehr so gerne gesehen, wenn einfach ein .jar auf einen PC kopiert und ausgeführt wird. Dafür sollten dann auch spezielle Softwareverteilungstools eingesetzt werden.

Ich habe mich einfach ein bisschen an der Standardaussage "gestört" ein LTS zu verwenden. Das es dann da Ausnahmen und Sonderfälle gibt ist klar... (Ich habe z.B. gerade letzte Woche ein jdk7 auf einem Server installieren müssen um ein Tool von einem externen Lieferanten zu verwenden.)

Das ist aber auch nur meine persönliche Meinung und jeder darf gerne andere haben. Falsch und Richtig gibt es ja bekanntlich selten.

 

[LimDul]

Genau auf das wollte ich hinaus... Mit den von @kneitzel auch schon erwähnten Tools, kann man ohne Probleme ein massgenschneidertes JRE direkt mitausliefern.

Sich auf ein installiertes JRE zu verlassen ist schwierig, sobald man sich nicht mehr in einem gemangten Umfeld mehr befindet. Und in diesen Umfeldern ist es dann auch nicht mehr so gerne gesehen, wenn einfach ein .jar auf einen PC kopiert und ausgeführt wird. Dafür sollten dann auch spezielle Softwareverteilungstools eingesetzt werden.

Ich habe mich einfach ein bisschen an der Standardaussage "gestört" ein LTS zu verwenden. Das es dann da Ausnahmen und Sonderfälle gibt ist klar... (Ich habe z.B. gerade letzte Woche ein jdk7 auf einem Server installieren müssen um ein Tool von einem externen Lieferanten zu verwenden.)

Das ist aber auch nur meine persönliche Meinung und jeder darf gerne andere haben. Falsch und Richtig gibt es ja bekanntlich selten.

Ich glaube dann sind wir uns relativ einig.

- Liefere ich die Umgebung mit aus, dann eine aktuell supportete Version. Das kann eine LTS Version sein, dass kann das aktuellste OpenJDK sein, dass kann sonst was sein.
- Muss die Umgebung bereit gestellt werden, dann muss man das nehmen was bereit gestellt wird. Wenn man es nicht weiß, dann ist die aktuellste LTS Version der Best Guess.

 

[mrBrown]

https://www.reddit.com/r/java/comments/kappmi/_/gffj7sg

Moving from 11 to 17 gives you the worst of both worlds. You end up investing more effort in the upgrade, which may have removed API elements without any deprecation warnings (the JDK's development process ignores which versions companies choose to sell LTS for) as well as missing out on constant performance improvements and features. LTS is mostly for legacy, or applications that aren't heavily developed, and when chosen appropriately, it's best to remain on such a version for 5-6 years so as not to end up spending too much effort on migration. If you want 17, you might as well use 16. And if you want LTS and are currently on 11, you probably don't want 17 and might want to wait a few more years, as your application doesn't need or want new features, anyway.

Put another way, if you're eagerly waiting for a new release with LTS, LTS probably isn't for you. If you're looking with horror at a new release with LTS as signifying the end of updates for your current version, then it is for you. Or even more simply, the law of Java LTS is: if you want it -- you don't need it; if you need it -- you don't want it.

Ich möchte nicht ständig auf eine neue Version upgraden müssen, aber trotzdem noch Sicherheitsupdates und Fehlerbehebung erhalten (Wobei: gilt das auch für Java? Weiß ich nicht, vielleicht kann ein Wissender was dazu sagen).

Ja, Patches werden auch zurückportiert.
Wenn man aber sowieso updated, dann kann man auch direkt auf die neuste Major-Version updaten.

- Liefere ich die Umgebung mit aus, dann eine aktuell supportete Version. Das kann eine LTS Version sein, dass kann das aktuellste OpenJDK sein, dass kann sonst was sein.
- Muss die Umgebung bereit gestellt werden, dann muss man das nehmen was bereit gestellt wird. Wenn man es nicht weiß, dann ist die aktuellste LTS Version der Best Guess.

Wobei ich eher die vorherige LTS als "Best Guess" bezeichnen würde. Wie du ja selbst sagtest, Java 11 ist für viele noch zu neu (und daran wird sich vermutlich auch innerhalb des nächsten Jahres nichts dran ändern :/).

EDIT:

immer auf die aktuelleste JRE zu wechseln und das für Features, die vermutlich gar nicht genutzt werden

Die genutzten Features sind besseres Laufzeitverhalten – neuere Versionen sind üblicherweise schneller, weniger Speicherlastig, der GC arbeitet besser und sie laufen stabiler.
Features in der Sprache selbst sind ja nur ein kleiner Teil dessen, was neue Versionen mit sich bringen.

 

[Udo_von_ESA]

Vielen Dank für die vielen Ratschläge. Leider ist mein Problem jedoch:

Die aktuellen Versionen sind:

• Java Development Kit (JDK): "Java SE 15.0.1" (Quelle: www.oracle.com)
• Java Runtime Environment (JRE): "jre-8u271-windows-x64.exe" (Quelle: www.java.com)

Ich möchte ja die neueste JRE verwenden. Leider finde ich nur Version 8 im Internet. Wo bekomme ich eine Runtime V15 her?
Oder muss ich tatsächlich das Development Kit zerpflücken um eine aktuelle Runtime isolieren zu können?

 

[kneitzel]

Dann noch einmal in Kürze die wichtigen Punkte:
Ja, Oracle bietet keine aktuelleren JRE an.

Optionen:
a) Man kann auch einfach das ganze JDK installieren.
b) Es gibt andere Anbieter, z.B. AdoptOpenJDK (https://adoptopenjdk.net/). Da finden sich auch JREs (Andere Plattformen auswählen um auch die JRE angezeigt zu bekommen.)
c) Gib kein einfaches JAR File weiter! Das ist eine Support Hölle, in die Du nicht möchtest! Gibt (native) Images raus! Also per JLink ein Image erzeugen und dann per JPackage zusammen packen. Das ist relativ einfach, so man Maven oder Gradle nutzt (Dazu würde ich eh immer raten!)

 

[mrBrown]

zB hier: https://www.azul.com/downloads/zulu-community/?package=jre
oder hier: https://adoptopenjdk.net/releases.html?variant=openjdk15&jvmVariant=hotspot
oder hier: https://bell-sw.com/pages/downloads/#/java-15-current
oder hier: https://sap.github.io/SapMachine/

 

[LimDul]

Vielen Dank für die vielen Ratschläge. Leider ist mein Problem jedoch:

Ich möchte ja die neueste JRE verwenden. Leider finde ich nur Version 8 im Internet. Wo bekomme ich eine Runtime V15 her?
Oder muss ich tatsächlich das Development Kit zerpflücken um eine aktuelle Runtime isolieren zu können?

Es gibt keine separaten JREs (Edit: von Oracle) mehr, wie @kneitzel schrieb, ist der präfierte Weg jetzt eine Lauffähige Anwendung mit den Teilen der Runtime zu bauen, die man wirklich braucht.