Der Wechsel von Oracle JDK auf eine freie OpenJDK-Distribution ist technisch in den meisten Fällen unkritisch. Beide beruhen auf derselben Codebasis, das OpenJDK-Projekt steht unter der GPL mit Classpath Exception und ist für den Produktivbetrieb kostenfrei nutzbar. Die eigentliche Frage betrifft den Support: Wer liefert Sicherheitsupdates, in welcher Frist, und wie lange für eine bestimmte Version?

Distribution ist nicht gleich Distribution

Aus dem OpenJDK-Quellcode entstehen mehrere gepflegte Builds, unter anderem von Eclipse Adoptium, Amazon, Microsoft, Red Hat, BellSoft, IBM und Azul. Funktional entsprechen sie bei den LTS-Versionen dem Oracle JDK. Unterschiede gibt es bei den Zusagen: wie schnell nach einem Sicherheitsupdate ein Build bereitsteht, wie lange eine Version überhaupt weiter gepflegt wird und für welche Betriebssysteme und Architekturen es fertige Pakete und Container-Images gibt.

Ein erster Prüfpunkt ist die Zertifizierung. Ein Build sollte das Technology Compatibility Kit für die jeweilige Java-SE-Version bestanden haben. Damit ist belegt, dass er dem Standard entspricht und Anwendungen sich wie erwartet verhalten. Der zweite Prüfpunkt sind die Update-Zeiträume, die sich je Distribution und Version deutlich unterscheiden, gerade bei älteren Versionen wie Java 8 und 11.

Was ein Supportvertrag zusätzlich leistet

Frei verfügbare Builds decken den Normalfall ab. Ein kommerzieller Supportvertrag ergänzt Reaktionszeiten, benannte Ansprechpartner, Unterstützung bei Fehlern in der Laufzeitumgebung und häufig Sicherheits-Backports für Versionen, die andere nicht mehr pflegen. Für regulierte Bereiche ist zudem die Nachweisbarkeit relevant: Gegenüber Prüfern lässt sich belegen, wer die Laufzeitumgebung pflegt und in welcher Frist Schwachstellen behoben werden.

Ein Unterschied betrifft das Preismodell. Kommerzieller OpenJDK-Support wird üblicherweise nach Servern, Prozessoren oder Instanzen abgerechnet, also nach dem tatsächlichen Einsatz. Die Oracle Java SE Universal Subscription rechnet dagegen nach der Gesamtzahl der Mitarbeiter. Genau daraus ergibt sich in vielen Umgebungen der Kostenunterschied.

„Die Frage ist nie, ob OpenJDK funktioniert, sondern wer im Ernstfall haftet und liefert. Für ein Testsystem reicht ein freier Build. Für eine Anwendung, an der das Kerngeschäft hängt, will jeder Betriebsleiter einen Vertrag mit Fristen“, sagt Markus Oberg, Partner und Business Development Manager der ProLicense.

Die Umstellung sauber abschließen

Der Wechsel wirkt nur, wenn er vollständig ist. Deshalb gehört an den Anfang eine Inventur aller Java-Installationen, einschließlich der Laufzeitumgebungen, die in Drittsoftware mitgeliefert werden. Für jede betroffene Anwendung ist zu prüfen, ob der Hersteller den Betrieb auf der gewählten Distribution unterstützt. Danach folgen Tests in Entwicklungs- und Abnahmeumgebungen, bevor die Produktion umgestellt wird.

Am Ende steht die Dokumentation: welche Oracle-JDK-Installationen wann entfernt wurden und welche Distribution seitdem im Einsatz ist. Diese Unterlagen sind die Grundlage, falls Oracle später Fragen zur Java-Nutzung stellt.

„Nach einem Umstieg kommen die Fragen von Oracle oft erst mit Verzögerung, gestützt auf Download-Daten aus der Vergangenheit. Wer dann für jeden Server zeigen kann, was wann entfernt und was installiert wurde, beendet das Gespräch schnell. Ohne Dokumentation wird daraus eine Verhandlung“, sagt Christian Grave, Geschäftsführer der ProLicense.

ProLicense berät bei Auswahl, Kostenvergleich und Umstellung herstellerunabhängig auf Kundenseite und ist zugleich Partner von Azul, einem der Anbieter kommerzieller OpenJDK-Distributionen. Bei Rückfragen von Oracle unterstützt ProLicense in der Auditabwehr. Ziel bleibt minimale Kosten bei voller Compliance. Anfragen nimmt ProLicense über die Kontaktseite entgegen.