Sinnvolle Bereitstellung mehrerer JRE in einer Unternehmensumgebung

[_basti]

Hallo zusammen,

Vorneweg: Ich bin selbst kein Java-Entwickler (so wirklich gar nicht!) bin bei uns im Unternehmen neuerdings aber für die Bereitstellung der Java Runtime Environment für die Clientsysteme verantwortlich.

Bisher war auf sämtlichen Clients nur die Java 8 Runtime Environment in 32bit + 64bit (von Oracle) parallel installiert.
Jetzt gab es zuletzt Anfragen das für diverse Anwendungen auch neuere Java Versionen benötigt werden.
Der Plan war jetzt eigentlich weiterhin Java 8 in 32 und 64 bit auf den Clients zu verteilen - da nach wie vor für diverse Anwendungen benötigt - und zusätzlich eine Java 11 JRE dazu zu packen, welche über << jlink.exe --add-modules ALL-MODULE-PATH >> extrahiert wurde.
Dazu entsprechende JAVA_HOME Variablen gesetzt (für alle 3 JREs) und auf eine davon über die PATH-Variable verlinkt.

In ersten Tests hat das soweit auch funktioniert und eine TEST.jar Datei kann mit der entsprechenden Variable vorneweg aufgerufen werden!

Wie es dann so ist, kamen prompt neue Anforderungen, dass nicht mehr nur 11 sondern ggf. auch 17 und/oder 21 benötigt werden.

Jetzt stellen sich mir hier gerade in paar Grundsatzfragen wie man denn da am besten mit umgeht.
Der Ursprungsgedanke war ja der, dass wir zentral auf allen Clients die benötigten JREs im vollen Umfang zur Verfügung stellen, damit nicht jede Anwendung eine eigene JRE mitbringen muss.
Bis Java 8 war das nach meinem Verständnis nach ja auch so noch das Standardvorgehen.
Ab Java 11 gibt es dann ja die Module, damit (wenn ich es richtig verstanden habe) die einzelnen Applikationen ihre eigene JRE in reduziertem Umfang mitbringen können.
Macht es also überhaupt Sinn das Java >= 8 noch zentral zur Verfügung zu stellen? Wir bräuchten dann im ungünstigsten Fall ja ggf. (ein) Paket(e) für 8 + 11 + 17 + 21 um alles abzudecken, da wir nie wissen welche Applikation welche Version gerade braucht.

Funktioniert das technisch überhaupt noch, dass sich mehrere Applikationen die gleiche JRE "teilen" (mit allen Modulen breitgestellt)?
Rein von der Logik wäre es ja schon sinnvoll zentral etwas bereit zu stellen, anstatt das 50 Anwendungen jeweils 50 eigene JREs mitbringen.
Blöd nur, wenn theoretisch z.B. nur 1 davon Java 11 in minimalem Umfang braucht und die anderen alle 8 und 17 oder so.

Wie seht ihr die Pro- und Contra Punkte bei dem geplanten Vorgehen - oder habe ich technisch ggf. etwas übersehen was noch beachtet werden muss?

Danke für eure Meinungen!

Gruß Basti

 

[M.L.]

beachtet

Man kann die passende(n) Runtime(s) auch zusammenstellen: Stichwort JLink Oder mit Docker (+Kubernetes) simulieren, wie sich ein Java-Programm unter verschiedenen Betriebssystemen und Java Runtimes verhält.

 

[KonradN]

Also mit dem JLink / JPackage ist es meiner Meinung nach tatsächlich so, dass die Anwendungen jeweils ihre eigene JRE mitbringen. Damit entfällt die Notwendigkeit, diese JRE Systemweit zu installieren. Bei 50 Anwendungen sind dann aber auch 50 JRE auf dem System. Das ist aber aus meiner Sicht eine Sache der Software Entwickler. Sprich: Ich entwickle eine Anwendung und dann kommt da am Ende eine Anwendung heraus, die ich weiter gebe und da ist dann halt auch alles drin, was man braucht. (JLink und JPackage sind daher eher etwas für den Software Entwickler und nicht für den Admin, der dann das Unternehmensnetz verwaltet oder so.)

Aus Sicht eines Admins wäre in einer Windows Enterprise Umgebung eher das MDOP zu nennen mit App-V. Dann hast du halt die einzelnen Anwendungen, die Du bereit stellen willst, und da kannst Du Abhängigkeiten beliebig bereit stellen. Das App-V Paket zu Java Anwendung 1 hat dann eine Abhängigkeit zu Java 1.8 und die Java Anwendung 2 hat dann z.B. Java 21. Und durch die Virtualisierung kann die App sogar spezielle Anpassungen haben, also wenn ein Hersteller da irgend welche Anpassungen fordert: Macht man dann halt. Das ist dann halt nur in der Bubble der App.

Das ist aber schnell Overkill - vor allem, wenn man da noch keine Erfahrungen gesammelt hat.

Ansonsten ist der Weg, den Du beschrieben hast, vollkommen ok:

• die JREs, die man will, einfach irgendwohin entpacken (Damit stehen alle Module zur Verfügung. Es gibt keine Selektion per JLink!)
• dann JAVA_HOME (und Path) setzen
• und die Anwendung aufrufen.

Das ist dann aber halt alles kein "Anwender lädt ein JAR herunter und öffnet es mit Doppelklick". Das System hat halt nur ein JRE für sowas. Da könnte man schauen, mit welchem JRE man am Besten klar kommt, aber da wird es immer Abstriche und Probleme geben.

Und wenn man einen Anbieter haben will, der keine JREs mehr bereit stellen sollte, dann nimmt man ein volles JDK - da ist ja ein JRE mit dabei!

Also zu den Fragen noch einmal ganz klar:

Funktioniert das technisch überhaupt noch, dass sich mehrere Applikationen die gleiche JRE "teilen" (mit allen Modulen breitgestellt)?

Ja, das geht. entweder einfach über JAVA_HOME und PATH oder eben über Lösungen wie App-V.

Wie seht ihr die Pro- und Contra Punkte bei dem geplanten Vorgehen - oder habe ich technisch ggf. etwas übersehen was noch beachtet werden muss?

Die Modulauswahl ist keine Sache der Admins. Wenn die Entwickler sowas nicht vorgesehen haben, dann hat eine Anwendung alle Module. Das wäre der wichtige Punkt, weil Du da etwas mit JLink machen willst. Aber wenn es Dir um die Bereitstellung anderer Anwendungen geht, dann ist das ein Punkt, den Du nicht machen solltest. Als Admin folgt man den Vorgaben der Hersteller. (Und da hilft APP-V - wenn der Hersteller sagt: Lösche fast alles aus SYSTEM32, dann juckt mich das nicht. Die Bubble von der Anwendung hat das dann halt!)