Oracle JDK oder OpenJDK: welche Java-Distribution ihr kostenfrei einsetzen dürft
Derselbe Quellcode, unterschiedliche Bedingungen. Wer im Haus welche Entscheidung trifft und woran das Ganze in der Praxis scheitert.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Niemand hat etwas beschafft, und trotzdem steht plötzlich eine Rechnung im Raum
Java landet selten über den Einkauf im Haus. Es kommt mit einem Produkt mit, das eine Laufzeitumgebung mitbringt, es wird von einer Entwicklerin auf ihrem Rechner installiert, weil eine Anleitung es so sagt, oder es steckt in einem Container-Basisabbild, das jemand vor drei Jahren gewählt hat. Keiner dieser Vorgänge geht über eine Freigabe, und deshalb existiert auch keine Liste. Wenn dann eine Anfrage kommt, was im Haus läuft, beginnt eine Suche, die Wochen dauern kann.
Erschwert wird das durch eine Formulierung, die sich hartnäckig hält: Java sei nicht mehr kostenlos. Das ist in dieser Form falsch. Die Bedingungen betreffen ausschließlich die Builds, die Oracle unter eigenem Namen ausliefert, und auch dort nur bestimmte Versionen in bestimmten Zeitfenstern. Wer Eclipse Temurin, Amazon Corretto oder eine andere Distribution einsetzt, hat mit dieser Frage schlicht nichts zu tun. Solange im Haus aber niemand weiß, was wo installiert ist, lässt sich das nicht sagen, und diese Unsicherheit ist der eigentliche Aufwandstreiber.
Dazu kommt eine zeitliche Falle, die viele erst bemerken, wenn sie zuschnappt. Die kostenfreie Nutzung eines Oracle JDK ist nicht dauerhaft, sondern an ein Fenster gebunden, das etwa ein Jahr nach dem Erscheinen der nächsten Langzeitversion endet. Für Oracle JDK 17 ist dieses Fenster im September 2024 abgelaufen, für Oracle JDK 21 endet es im September 2026. Wer die Version einmal freigegeben und danach nicht mehr angesehen hat, wechselt in diesem Moment ohne eigenes Zutun die Lizenzgrundlage.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Wer im Haus was entscheidet
Die meisten Probleme in diesem Bereich sind keine technischen, sondern Zuständigkeitsfragen. Die folgende Aufteilung hat sich bewährt, weil sie jede Entscheidung genau einer Stelle zuordnet und jedes Mal benennt, woran es in der Praxis scheitert.
| Thema | Wer entscheidet | Wer setzt um | Stolperfalle |
|---|---|---|---|
| Welche Java-Distribution im Haus Standard ist | Die Architektur gemeinsam mit dem Betrieb, einmalig und schriftlich, mit Begründung und einem Datum für die Überprüfung | Der Betrieb, indem er die Distribution im internen Paketverzeichnis und in den Basisabbildern bereitstellt | Der Beschluss existiert, aber die Distribution ist intern schwerer zu bekommen als der Download bei Oracle. Dann gewinnt die Bequemlichkeit, und zwar jedes Mal. |
| Der Einsatz eines Oracle JDK in einem einzelnen Projekt | Die Stelle, die für Lizenzen und Verträge zuständig ist, nicht das Projekt und nicht der Betrieb | Das Projekt, mit einem Eintrag im Bestandsverzeichnis und einer Begründung, warum die Standarddistribution nicht ausreicht | Der Fall wird als technische Kleinigkeit behandelt und läuft an der zuständigen Stelle vorbei, weil niemand ihn als Beschaffung erkennt. |
| Der Nachweis darüber, was auf Servern und Arbeitsplätzen läuft | Die Stelle, die für die Inventarisierung ohnehin zuständig ist, entlang derselben Regeln wie bei anderer Software | Der Betrieb über die vorhandene Inventarisierung, ergänzt um die Herstellerzeile aus java -version und die Suche nach eingebetteten Laufzeitumgebungen | Erfasst wird nur die Versionsnummer. Damit lässt sich die eigentliche Frage nicht beantworten, denn sie hängt am Hersteller und nicht an der Zahl. |
| Die Basisabbilder für Container | Die Plattformverantwortlichen, im Rahmen der ohnehin bestehenden Vorgaben für Images | Der Bauprozess, indem er nur Images aus der eigenen Registry zulässt und alles andere ablehnt | Die Regel gilt für neue Projekte, und der Bestand läuft weiter mit dem, was vor Jahren einmal kopiert wurde. Ohne eine Bestandsprüfung bleibt genau dort das Risiko. |
| Das Auslaufen einer kostenfreien Phase bei einem Oracle JDK | Wer für das jeweilige Produkt im Betrieb geradesteht, nicht die Person, die den Hinweis zuerst liest | Das Team, entweder durch den Wechsel auf eine freie Distribution derselben Version oder durch den Sprung auf die nächste Langzeitversion | Der Termin verstreicht unbemerkt, weil weiterhin Updates verfügbar sind. Verändert hat sich nicht die Verfügbarkeit, sondern die Lizenz, unter der sie steht. |
| Eine Anfrage zur Prüfung des Java-Einsatzes | Die Rechts- oder Vertragsabteilung, die auch sonst mit Herstelleranfragen umgeht | Der Betrieb, indem er den aktuellen Stand aus dem Inventar liefert, statt kurzfristig eine neue Erhebung zu starten | Die Antwort wird unter Zeitdruck aus verstreuten Quellen zusammengesucht. Ein gepflegtes Inventar verwandelt diesen Vorgang in eine Abfrage von wenigen Minuten. |
Welche Java-Distribution im Haus Standard ist
- Wer entscheidet
- Die Architektur gemeinsam mit dem Betrieb, einmalig und schriftlich, mit Begründung und einem Datum für die Überprüfung
- Wer setzt um
- Der Betrieb, indem er die Distribution im internen Paketverzeichnis und in den Basisabbildern bereitstellt
- Stolperfalle
- Der Beschluss existiert, aber die Distribution ist intern schwerer zu bekommen als der Download bei Oracle. Dann gewinnt die Bequemlichkeit, und zwar jedes Mal.
Der Einsatz eines Oracle JDK in einem einzelnen Projekt
- Wer entscheidet
- Die Stelle, die für Lizenzen und Verträge zuständig ist, nicht das Projekt und nicht der Betrieb
- Wer setzt um
- Das Projekt, mit einem Eintrag im Bestandsverzeichnis und einer Begründung, warum die Standarddistribution nicht ausreicht
- Stolperfalle
- Der Fall wird als technische Kleinigkeit behandelt und läuft an der zuständigen Stelle vorbei, weil niemand ihn als Beschaffung erkennt.
Der Nachweis darüber, was auf Servern und Arbeitsplätzen läuft
- Wer entscheidet
- Die Stelle, die für die Inventarisierung ohnehin zuständig ist, entlang derselben Regeln wie bei anderer Software
- Wer setzt um
- Der Betrieb über die vorhandene Inventarisierung, ergänzt um die Herstellerzeile aus java -version und die Suche nach eingebetteten Laufzeitumgebungen
- Stolperfalle
- Erfasst wird nur die Versionsnummer. Damit lässt sich die eigentliche Frage nicht beantworten, denn sie hängt am Hersteller und nicht an der Zahl.
Die Basisabbilder für Container
- Wer entscheidet
- Die Plattformverantwortlichen, im Rahmen der ohnehin bestehenden Vorgaben für Images
- Wer setzt um
- Der Bauprozess, indem er nur Images aus der eigenen Registry zulässt und alles andere ablehnt
- Stolperfalle
- Die Regel gilt für neue Projekte, und der Bestand läuft weiter mit dem, was vor Jahren einmal kopiert wurde. Ohne eine Bestandsprüfung bleibt genau dort das Risiko.
Das Auslaufen einer kostenfreien Phase bei einem Oracle JDK
- Wer entscheidet
- Wer für das jeweilige Produkt im Betrieb geradesteht, nicht die Person, die den Hinweis zuerst liest
- Wer setzt um
- Das Team, entweder durch den Wechsel auf eine freie Distribution derselben Version oder durch den Sprung auf die nächste Langzeitversion
- Stolperfalle
- Der Termin verstreicht unbemerkt, weil weiterhin Updates verfügbar sind. Verändert hat sich nicht die Verfügbarkeit, sondern die Lizenz, unter der sie steht.
Eine Anfrage zur Prüfung des Java-Einsatzes
- Wer entscheidet
- Die Rechts- oder Vertragsabteilung, die auch sonst mit Herstelleranfragen umgeht
- Wer setzt um
- Der Betrieb, indem er den aktuellen Stand aus dem Inventar liefert, statt kurzfristig eine neue Erhebung zu starten
- Stolperfalle
- Die Antwort wird unter Zeitdruck aus verstreuten Quellen zusammengesucht. Ein gepflegtes Inventar verwandelt diesen Vorgang in eine Abfrage von wenigen Minuten.
Vom Bestand zur belastbaren Aussage
- 01 Was ist installiert? Version und Herstellerzeile erfassen, nicht nur die Zahl.
- 02 Ist ein Oracle-Build dabei? Nur dann stellt sich die Lizenzfrage überhaupt.
- 03 Welche Version, und liegt sie noch im kostenfreien Fenster?
- 04 Gibt es eine festgelegte Standarddistribution, die Projekte einfach nehmen können?
- 05 Stehen die Ablauftermine in einem Kalender, den jemand ansieht?
Was ihr im Haus tatsächlich klären müsst
Die Frage lässt sich in sechs Schritten dauerhaft beantworten. Vier davon sind einmalige Festlegungen, zwei sind laufende Vorgänge, die in bestehende Abläufe eingebaut werden können.
Version und Distribution auseinanderhalten
Java 21 ist eine Version, Eclipse Temurin 21 ist ein Build davon. Die Version bestimmt, was euer Code kann. Der Build bestimmt, unter welchen Bedingungen ihr Updates bekommt und wer haftet, wenn etwas nicht funktioniert. Trennt diese beiden Fragen in jedem Dokument und in jedem Gespräch, sonst führt ihr zwei Diskussionen gleichzeitig und beenden könnt ihr keine davon.
Eine Standarddistribution festlegen und begründen
Für die meisten Häuser ist die Antwort eine der frei verfügbaren Distributionen. Eclipse Temurin sagt für Langzeitversionen mindestens vier Jahre Builds zu und nennt konkrete Termine je Version. Amazon Corretto veröffentlicht ebenfalls eigene Zeitpläne, die für 17, 21 und 25 jeweils weit über Oracles kostenfreie Phase hinausreichen. Schreibt die Wahl mit Begründung auf, sonst wird sie in jedem Projekt neu verhandelt.
Ein Inventar aufbauen, das die Herstellerzeile mitnimmt
java -version gibt zwei Zeilen aus, und die zweite ist die wichtigere: Dort steht, wessen Build läuft. Eine Bestandsaufnahme, die nur die Versionsnummer erfasst, beantwortet die Lizenzfrage nicht. Nehmt die Erhebung in eure bestehende Inventarisierung auf und lasst sie regelmäßig laufen, denn ein einmaliger Stand veraltet in dem Moment, in dem jemand ein Basisabbild aktualisiert.
Entwicklerrechner und Produkte von Drittanbietern mitzählen
Der häufigste Fund ist nicht der Server, sondern der Arbeitsplatz: Jemand hat sich ein JDK direkt bei Oracle heruntergeladen, weil das der erste Treffer war. Der zweithäufigste ist ein gekauftes Produkt, das eine eigene Laufzeitumgebung mitbringt. Für den ersten Fall braucht ihr eine bequeme Alternative im internen Paketverzeichnis, für den zweiten eine Klärung mit dem Hersteller darüber, wie dessen Laufzeitumgebung lizenziert ist.
Basisabbilder zentral festlegen statt pro Projekt
In Container-Landschaften entscheidet die erste Zeile einer Containerdatei über die Distribution, und diese Zeile wird kopiert, nicht gelesen. Legt geprüfte Basisabbilder in eurer eigenen Registry ab und lasst den Bauprozess ablehnen, was von woanders kommt. Damit ist die Frage für den größten Teil der Landschaft ein für alle Mal beantwortet, und Aktualisierungen laufen an einer Stelle.
Die Ausstiegstermine in den Kalender legen
Für jede eingesetzte Version gibt es zwei relevante Daten: das Ende des Supports bei eurer Distribution und, falls ein Oracle JDK im Spiel ist, das Ende der kostenfreien Phase. Beide gehören in denselben Kalender wie eure Zertifikatsabläufe. Ein Termin, der nur in einem Beschlussdokument steht, wird zuverlässig übersehen.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Drei Lizenzen, und woran ihr sie auseinanderhaltet
Der Quellcode von Java liegt im OpenJDK-Projekt und steht unter der GNU General Public License Version 2 mit Classpath-Ausnahme. Diese Ausnahme ist der Grund, warum eure eigene Anwendung dadurch nicht selbst unter diese Lizenz fällt. Alle verbreiteten Distributionen bauen aus diesem Quellcode, und die Builds, die Oracle unter dem Namen OpenJDK auf jdk.java.net veröffentlicht, stehen ebenfalls darunter. Sie werden allerdings nur bis zum Erscheinen der nächsten Version gepflegt, sind also kein Weg für den Dauerbetrieb.
Die zweite Lizenz ist die No-Fee Terms and Conditions License, kurz NFTC. Sie gilt seit September 2021 für die Oracle-JDK-Builds und erlaubt ausdrücklich die kostenfreie Nutzung für alle, auch kommerziell und im Produktivbetrieb. Ihre Einschränkung ist zeitlich: Eine Langzeitversion bleibt darunter bis etwa ein Jahr nach dem Erscheinen der nächsten Langzeitversion. Für Oracle JDK 21 ist das der September 2026, für Oracle JDK 25 nach heutiger Planung der September 2028. Nicht-Langzeitversionen bleiben für ihre gesamte, auf sechs Monate angelegte Lebensdauer darunter.
Die dritte ist die Oracle Technology Network License Agreement for Java SE, kurz OTN. Sie erlaubt die persönliche Nutzung sowie Entwicklung, Test, Prototypenbau und Vorführung, aber nicht den Produktivbetrieb. Unter ihr stehen heute die Updates für Oracle JDK 8, 11 und 17, und ab Oktober 2026 sollen die Updates für Oracle JDK 21 dazukommen. Der entscheidende Punkt für die Praxis: Der Wechsel von NFTC zu OTN passiert an einem Stichtag und ändert nichts an der Verfügbarkeit der Downloads. Es ändert sich nur, was ihr damit tun dürft.
Die Distributionen und was sie tatsächlich zusagen
Alle relevanten Distributionen bauen aus demselben Quellcode und bestehen dieselbe Konformitätsprüfung, das Technology Compatibility Kit. Ein Programm, das auf der einen läuft, läuft auf der anderen. Der Unterschied liegt in den Zusagen darüber, wie lange es Builds gibt, wie schnell Sicherheitsupdates erscheinen und ob es kommerziellen Support gibt.
Eclipse Temurin von der Adoptium-Arbeitsgruppe ist die verbreitete Antwort für Häuser, die keinen Support kaufen wollen. Adoptium sagt für Langzeitversionen mindestens vier Jahre Builds zu und veröffentlicht konkrete Termine je Version. Amazon Corretto veröffentlicht eigene Zeitpläne, die derzeit für Corretto 17 bis Oktober 2029, für Corretto 21 bis Oktober 2030 und für Corretto 25 bis Oktober 2032 reichen. Daneben stehen unter anderem Azul, Red Hat, Microsoft, BellSoft, SAP und IBM mit eigenen Builds, teils mit kostenpflichtigem Support, teils ohne.
Für die Entscheidung heißt das: Die Frage lautet nicht, welche Distribution technisch besser ist, denn dieser Unterschied ist gering. Sie lautet, wessen Zusagen zu eurem Betriebsmodell passen. Wer im Störfall jemanden anrufen können muss, braucht einen Vertrag, und dann ist Oracle nur eine von mehreren Möglichkeiten. Wer den Betrieb selbst trägt, nimmt eine der frei verfügbaren Distributionen und achtet auf deren veröffentlichte Termine.
Warum das Abrechnungsmodell die Diskussion verändert hat
Seit Januar 2023 verkauft Oracle die Java SE Universal Subscription nach einer Kennzahl, die auf der Zahl der Beschäftigten beruht und nicht auf der Zahl der Personen, die Java tatsächlich benutzen. Oracle nennt in seinen eigenen Angaben einen Einstiegspreis von 15 US-Dollar je Beschäftigtem und Monat, mit veröffentlichten Staffeln bis hinunter zu 5,25 US-Dollar. Wie der Begriff genau abgegrenzt ist, steht in Oracles Preisliste, und die Abgrenzung ist der Punkt, an dem sich die Summe entscheidet.
Die praktische Folge ist eine andere Rechnung als früher. Wenn ein einzelner Server oder ein einzelner Arbeitsplatz eine Verpflichtung für das gesamte Haus auslösen kann, dann ist ein aufgeräumter Bestand kein Verwaltungsthema mehr, sondern eine Kostenfrage. Genau deshalb lohnt sich die Arbeit am Inventar und an den Basisabbildern auch dann, wenn heute niemand vorhat, etwas zu kaufen.
Umgekehrt gilt: Wenn ihr Support wollt, ist ein Vertrag eine legitime und oft sinnvolle Entscheidung, und Oracle bietet dabei mehr als nur Updates. Die Frage ist dann nicht ob, sondern bei wem, denn mehrere Anbieter liefern kommerziellen Support für dieselben Java-Versionen zu anderen Kennzahlen. Ein Vergleich lohnt sich, und er ist deutlich einfacher zu führen, wenn ihr vorher wisst, was bei euch läuft.
Der Weg heraus, wenn ein Oracle JDK im Bestand steckt
Der Wechsel selbst ist technisch klein. Eine andere Distribution derselben Java-Version ist ein Austausch des Installationspakets oder eine geänderte Zeile im Basisabbild, danach läuft dieselbe Anwendung weiter. Was Zeit kostet, ist nicht der Wechsel, sondern die Feststellung, wo überall gewechselt werden muss, und die anschließende Prüfung, dass nichts Unerwartetes passiert ist. Plant den Test wie bei einem Versionswechsel, auch wenn die Versionsnummer gleich bleibt.
Zwei Stellen verdienen dabei besondere Aufmerksamkeit. Die erste sind Produkte von Drittanbietern, die eine eigene Laufzeitumgebung mitbringen: Dort dürft ihr oft gar nicht selbst wechseln, weil der Hersteller nur seine Zusammenstellung unterstützt. Klärt in diesen Fällen schriftlich, wie die mitgelieferte Laufzeitumgebung lizenziert ist, denn im Regelfall trägt der Hersteller das. Die zweite sind Anwendungen mit eigenen Startskripten, in denen der Pfad zu einem JDK fest verdrahtet ist. Diese Skripte findet ihr nur, indem ihr danach sucht.
Für die Zukunft hilft eine einfache Regel mehr als jede Richtlinie: Es muss leichter sein, die richtige Distribution zu bekommen als die falsche. Solange der Download bei Oracle drei Klicks kostet und das interne Paket eine Anfrage per Ticket, wird der Bestand immer wieder durchmischt. Ein internes Paketverzeichnis, ein geprüftes Basisabbild und ein Eintrag in der Einrichtungsanleitung für neue Arbeitsplätze erledigen mehr als jede Erinnerung im Intranet.
Dazu passende Kurse
Wenn Betrieb, Architektur und Einkauf bei dieser Frage aneinander vorbeireden, schaffen Java-Kurse für technische und entscheidende Rollen die gemeinsame Sprache dafür.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Wo du genau das übst
Sehr umfangreicher Überblick über Zusammenhänge und Anwendungsbereiche. Sehr zu empfehlen.
Effektives, gemeinsames Erarbeiten der Aufgaben mit vielen praktischen Tipps.
Sehr guter Trainer und gute Aufbereitung der Inhalte und auch eingehen auf Fragen der Beteiligten.
Häufige Fragen
Ist Java jetzt kostenpflichtig?
Wir haben Oracle JDK 21 im Einsatz. Was passiert im September 2026?
Zählt ein JDK auf einem Entwicklerrechner mit?
Unterscheiden sich die Distributionen technisch voneinander?
Was ist mit Java in gekaufter Software?
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem Programmierung-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Die Java-Landschaft im Haus einmal sauber aufstellen
Bei cmt bekommen technische und entscheidende Rollen in den Java-Kursen dieselbe Grundlage, damit die Diskussion über Versionen und Distributionen nicht jedes Mal von vorn beginnt.
Passt dazu
- Java 17, 21 oder 25: welche LTS-Version euer Projekt tragen sollte
- Von Java 8 wegkommen: was der Sprung auf eine aktuelle LTS wirklich verlangt
- OutOfMemoryError in Java: Heap, Metaspace und was der Dump verrät
- Spring Boot oder Quarkus: was Startzeit und Speicher im Betrieb kosten