Mit OpenJDK entwickeln aber Oracle SE Runtime installieren?

JavaDaHood

Mitglied
Hallo,

mich würde interessieren ob es möglich ist mit OpenJDK zu entwickeln und die Personen, welche dann die Applikation auf ihren Rechnern nutzen wollen, selbst Oracle SE Runtime etc. installieren müssen?
Ist das lauffähig?
Hintergrund ist der, dass man ja die Oracle-Produkte ohne Lizenz nicht in einen Installer der Applikation packen darf.

OpenJDK und Oracle auf demselben System geht ja wohl nicht.
 
mich würde interessieren ob es möglich ist mit OpenJDK zu entwickeln und die Personen, welche dann die Applikation auf ihren Rechnern nutzen wollen, selbst Oracle SE Runtime etc. installieren müssen?
Ja, in den aktuellen Versionen sind beide Versionen (nahezu) gleich. Sowohl Oracle JDK als auch die Oracle OpenJDK-Build als auch alle anderen OpenJDK-Builds bauen auf den gleichen Source auf. Die Unterschiede sind in den meisten Fällen nicht relevant (wenn sie überhaupt existent sind).

Hintergrund ist der, dass man ja die Oracle-Produkte ohne Lizenz nicht in einen Installer der Applikation packen darf.
Man darf Oracle JDK ohne Lizenz nicht mal produktiv nutzen 🙂
Das geht nur mit den Oracle OpenJDK-Builds oder anderen Builds von anderen "Herstellern".


OpenJDK und Oracle auf demselben System geht ja wohl nicht.
Klar geht das 🙂 man kann problemlos beliebige Versionen gleichzeitig installiert haben.
 
Warum lässt du deine Anwender den nicht eine OpenJRE version installieren, auf die du verweißt?
Weil es völlig egal ist, woher der Anwender sein JRE bekommt. Dem dann vorschreiben, welches JRE der nutzen soll, ist ziemlicher Unsinn 🙂

Wenn schon, dann mit JLink ein pasendes JRE bauen und mitliefern, dann muss der Anwedner gar nichts mehr installieren.
 
Wenn schon, dann mit JLink ein pasendes JRE bauen und mitliefern, dann muss der Anwedner gar nichts mehr installieren.
Das einfach noch etwas ausgeführt / ergänzt:

Aus Sicht des Herstellers (Oracle) werden derzeit zwei Wege angeboten:

a) Mit Java 9 ist JLink mit beim JDK / OpenJDK. Dieses Tool nutzt die definieren Module incl. Abhängigkeiten um dann ein Image zu erstellen, welches neben den Klassen des Projekts und allen Abhängigkeiten noch alle Elemente des JRE enthält, die benötigt werden. Dabei ist zu beachten: Es werden nur die benötigten Module kopiert, d.h. es ist kein komplettes JRE, das kopiert wird.
Das reicht noch nicht ganz, denn man will es ja als Paket Anderen geben können, somit braucht man einen Installer (Windows: msi / exe, Mac: pkg/dmg und Linux: deb/rpm). Da kommt dann jpackage (jep 343) ins Spiel, das genau da ansetzt (Verfügbar ab Java/OpenJDK 13 oder 14 - bin mir da jetzt nicht ganz sicher).

b) GraalVM. Dabei handelt es sich um eine Runtime, deren Ziel die Erstellung sogenannter Native Images ist. Dabei wird mit Hilfe eines Compilers ein ausführbares Executable erzeugt. Hat einiges mehr an Anforderungen (So benötigt man z.B. Visual Studio unter Windows, Xcode auf Macs und gcc und co unter Linux).

Erfahrungsgemäß ist die Einstiegshürde bei GraalVM am höchsten da hier auch schon das Setup mit am komplexesten ist. JLink selbst benötigt aber fast nichts, so dass dies speziell mit Gradle oder Maven extrem einfach zu nutzen ist. (Komplex wird es erst beim Thema Cross-Builds - also wenn man unter einer Plattform etwas für andere Plattformen bauen möchte. Aber es geht. Bei GraalVM ist dies so nur eingeschränkt möglich - so lassen sich z.B. für Mac keine Binaries unter Linux oder Windows bauen ...)

Beide Wege lassen sich über Open Source abdecken. Ersteres setzt nur das OpenJDK voraus, welches unter GPL steht. Da nur fertig übersetzte Dateien kopiert werden und nichts damit zusammen kompiliert wird, gibt es bezüglich des eigenen Codes keine Probleme mit der GPL:
GraalVM ist etwas komplizierter. Hier findet auch die GPL v2 Anwendung, aber mit der CLASSPATH Ausnahme. Damit ist es möglich mit dem eigenen Code native Binaries zu bauen ohne dass man seinen Code unter GPL stellen muss. Siehe diesbezüglich https://www.graalvm.org/faq/ und https://github.com/oracle/graal/blob/master/LICENSE

Das einfach einmal als kleine Ergänzung zu den Aussagen, die bereits getätigt wurden. Meine Empfehlung ist klar, sich den ersten Weg mit JLink und ggf JPackage anzusehen, da hier aus meiner Sicht der Einstieg am einfachsten ist und beim Setup am wenigsten schief gehen kann.
 
Ja, danke für die Ergänzung. Aber auch bei Quarkus hat man die entsprechenden Anforderungen an die native Compiler...

Aber ja: Nett, auch wenn ich noch auf Spring Boot setze. (Aber die Vorteile von Quarkus sehe ich alleine schon im JEE Standard konformen ..., aber evtl. übersehe ich da auch noch etwas, weil ich da bisher nicht den genauen Einblick habe ...)
 

Zurück
Oben