Wird Java jetzt kostenpflichtig?

Inhaltsverzeichnis

Die von Oracle im vergangenen Jahr angekündigten Veränderungen im Hinblick auf den Releasezyklus von Java und das ergänzende Supportmodell haben zu Verunsicherung in den Anwenderunternehmen sowie der Entwickler-Community geführt. Ausgehend von einem Vergleich der bisherigen Regelungen mit dem neuen Java-Releasezyklus gehen die Autoren der Frage nach, wie Unternehmen und Entwickler in Zukunft mit Java arbeiten können, und ob sie für Java bezahlen müssen. Abschließend präsentieren und diskutieren sie verschiedene Alternativen und Vorgehensweisen.

Der Java-Releasezyklus: alt versus neu

Bisher fiel es den meisten Entwicklern leicht, eine Anwendung auf einer unterstützten Version von Java zu entwickeln und zu betreiben. Bis Java 8 gewährte Oracle für jede Version verhältnismäßig lange Support. Updates pflegte der Anbieter sogar über die Freigabe der nachfolgenden Version hinaus.

Entwickler standen dadurch nur begrenzt unter Druck, zu einer neuen Version zu wechseln. Entsprechend langfristig gestaltete sich die Planung von Updates. In welchen Abständen bisher neue Java-Versionen erschienen und wie lange diese kostenlosen beziehungsweise kommerziellen Support von Oracle erhielten, macht Abbildung 1 deutlich.

Die Dauer, während der kostenloser Support für eine Java-Version – respektive parallel für zwei Versionen – zur Verfügung stand, gab Unternehmen meist genügend Zeit, um zur nächsten Version zu migrieren, ohne auf kommerziellen Support zurückgreifen zu müssen. In allen längerfristigen Projekten konnten sie die restliche Zeit durch dessen Zukauf überbrücken.

In Abbildung 2 ist der neue von Oracle angekündigte Releasezyklus dargestellt. Ab Java 9 erhalten die meisten Java-Versionen nur noch ein halbes Jahr Support. Nach sechs Monaten folgt die Anschlussversion, die ihrerseits wieder nur ein halbes Jahr zur Verfügung steht. Die bisher übliche Übergangszeit entfällt. Selbst wenn ein Unternehmen einen Vertrag mit Oracle abschließt, bleibt der auf die sechsmonatige Laufzeit der Java-Version begrenzt.

Oracle verabschiedet sich vom bisherigen Modell zugunsten von "Long Term Support"-Versionen (LTS), für die jeweils acht Jahre kostenpflichtiger Support verfügbar sind. Unternehmen dürfen die LTS-Versionen erst nach Abschluss eines Vertrags nutzen. Vielen Anwender, die bisher ohne ausgekommen sind, dürfte diese Neuerung unter Druck setzen.

Verschärfend kommen wichtige Änderungen hinzu, die den Einsatz des Oracle JDK beziehungsweise des Oracle JRE in Produktion betreffen: Ab Java 11 sind beide nur noch in Entwicklungs- und Testumgebungen kostenfrei nutzbar. Zwingende Voraussetzung für den Einsatz der Oracle JRE in Produktion ist der Abschluss eines kommerziellen Supportvertrags bei Oracle. Alternativ stellt Oracle JRE und JDK über das OpenJDK weiterhin kostenlos bereit. Das OpenJDK lässt sich grundsätzlich auch in Produktion kostenlos nutzen.

Warum führt Oracle solche Änderungen ein?

Die Frage warum Oracle den Releasezyklus und das Lizenzmodell so stark ändert, ist berechtigt und im Kontext anderer, vergleichbarer Projekte zu betrachten: Google Chrome oder die Programmiersprache Go bauen schon länger auf sehr kurze Zyklen, in denen neue Versionen erscheinen. Diese kurzen, iterativen Veröffentlichungen lassen sich meist mit dem darunterliegenden, agilen Prozess erklären, der in der Regel auch für die Anwender wesentliche Vorteile mitbringt.

Im Fall von Java liegt der der wichtigste Vorteil des schnelleren Releasezyklus darin, dass neue Funktionen schneller zur Verfügung stehen. Mussten Entwickler nach der Veröffentlichung von Java 7 noch drei Jahre auf Java 8 und die damit verbundenen neuen Funktionen wie Lambdas warten, stehen solche Verbesserungen in Zukunft binnen weniger Monate bereit. Auch wenn die Entwicklung neuer Features wie Lambdas oder des Java-Modulsystems natürlich nicht binnen eines halben Jahres fertiggestellt ist, soll zumindest deren Verfügbarkeit für alle Nutzer der JDK und JRE spätestens sechs Monate nach deren Fertigstellung gesichert sein.

In der Vergangenheit traten immer wieder Verzögerungen bei Releases auf, weil geplante oder versprochene Features nicht rechtzeitig fertig waren, und Oracle sie aber nicht auf die nächste Version verschieben wollte. Der neue Releasezyklus verkürzt etwaige Wartezeiten auf neue Funktionen. Der zweite Vorteil liegt bei Oracle: Das Unternehmen muss nicht mehr mehrere Java-Versionen parallel mit kostenlosem Support versorgen.

Anwenderunternehmen zwingt der neue Zyklus jedoch dazu, die Umstellung auf neue Java-Versionen deutlich kontinuierlicher einzuplanen und strenger zu verfolgen. Andererseits profitieren Unternehmen beziehungsweise Projekte, die sich bisher ein Java-Versions-Update nicht leisten konnten oder wollten, von den LTS-Versionen und deren verlängertem Supportzeitraum. Der kommerzielle Support gewinnt damit deutlich an Bedeutung, daher lohnt sich ein genauerer Blick auf die Konditionen und Preise.

Was kostet der kommerzielle Support von Oracle?

Mit dem neuen Java-Releasezyklus führt Oracle auch ein neues Modell für den kommerziellen Support ein. Dabei sind zwei Arten von Abonnements zu unterscheiden: das "Java SE Subscription"- und das "Java SE Desktop Subscription"-Modell.

Das "Java SE Subscription"-Modell ist allein für Serveranwendungen gedacht, die Abrechnung erfolgt pro Prozessor. Für Java-Client-Anwendungen ist das "Java SE Desktop Subscription"-Modell heranzuziehen, das pro Benutzer abzurechnen ist. Wollen Unternehmen sowohl Java-Server- wie auch Java-Client-Anwendungen nutzen, müssen sie beide Abonnements abschließen.

Anzahl Prozessoren	Monatlicher Preis pro Prozessor
1-99	$25.00
100-249	$23.75
250-499	$22.50
500-999	$20.00
1.000-2.999	$17.50
3.000-9.999	$15.00
10.000-19.999	$12.50
Ab 20.000 Prozessoren ist ein individueller Vertrag mit Oracle erforderlich.
Tabelle 1: Oracles kommerzielles Supportmodell "Java SE Subscription"

Das Modell ist einfach nachzuvollziehen, wenn man die Serveranwendungen auf physischen Maschinen betreibt. Sobald aber eine Anwendung in der Cloud oder in Containern hinzukommt, lässt sich die Aussage über genutzte CPUs nicht mehr einfach beantworten. Physische CPUs sind in diesem Fall über mehrere virtuelle Maschinen oder Container verteilt zugeordnet. Ob Oracle das Lizenzmodell für diesen Anwendungsfall noch optimiert, ist zum aktuellen Zeitpunkt noch offen.

Benutzer/Clients	Monatlicher Preis pro Benutzer/Client
1-999	$2.50
1.000-2.999	$2.00
3.000-9.999	$1.75
10.000-19.999	$1.50
20.000-49.999	$1.25
Ab 50.000 Benutzern/Clients ist ein individueller Vertrag mit Oracle erforderlich.
Tabelle 2: Oracles kommerzielles Supportmodell "Java SE Desktop Subscription"

Gerade für Desktopanwendungen gewinnt der kommerzielle Support an Bedeutung, da Oracle ab Java-Version 11 einige wichtige Desktop-Features aus dem JDK streicht. Unternehmen, die Java auf dem Desktop verwenden, finden dazu wichtige Informationen in der von Oracle Anfang 2018 angekündigten Java-Client-Roadmap.

Alle Details zum kommerziellen Oracle-Support finden sich auf der Java-Website. Vor allem Nutzer von Java WebStart sollten sich intensiv mit den anstehenden Änderungen auseinandersetzen.

Was bedeutet der neue Releasezyklus für meine Firma?

Mit Blick auf das Oracle JDK stehen Unternehmen drei mögliche Vorgehensweisen zur Auswahl, zwischen denen sie abwägen müssen.

1. Umstieg auf eine neue Java-Version alle 6 Monate. Wenn dies gelingt, baut man immer auf die aktuelle und kostenlos unterstützte Version auf. Gleichzeitig stehen dem Projekt dann immer die neuesten Funktions- und Sicherheitsupdates zur Verfügung.
2. Kauf von kommerziellem Support von Oracle. Dann migrieren Anwender immer von LTS-Version zu LTS-Version, wodurch allerdings jeweils große Versionssprünge notwendig sind. Beispielsweise steht Anfang 2019 der Wechsel von Java 8 auf Java 11 an, und dann 2022 von Java 11 auf Java 17.
3. Die Migration erfolgt weiterhin im Tempo des eigenen Projekts beziehungsweise nach Unternehmensrichtlinien. Kommerzieller Support entfällt vollständig oder lässt sich für die eigentlich notwendige Migration auf die neue Version durch extern eingekaufte Dienstleistung kompensieren.
   

Es ist durchaus zulässig, eine Java-Version ohne Updates und Bugfixes von Oracle zu verwenden – das spart Geld. Allerdings muss man dann auf alle veröffentlichten Bugfixes und Sicherheitsupdates verzichten. Bugfixes sind jedoch nur dann kritisch, wenn das Projekt von diesem Bug tatsächlich betroffen ist. Von der Behebung von Sicherheitslücken profitiert hingegen jedes Projekt. Deshalb ist diese Vorgehensweise nicht ohne Risiko und sollte genau überlegt sein.

Die skizzierten Vorgehensweisen sind alle drei valide. Die Wahl der bevorzugten hängt von verschiedenen Faktoren ab, beispielsweise der Bedeutung des Projekts, den Folgen bei einem Ausfall, dem Budget oder auch der Unternehmenspolitik und weiteren Punkten.

Die anstehenden Veränderungen im Java-Ökosystem versprechen Anwendern eine schnellere Verfügbarkeit von neuen Sprachfeatures. Die Neuerungen dürften auch schneller in Projekten zum Einsatz kommen. Features wie Generics (eingeführt mit Java 5) oder Lambdas (eingeführt mit Java 8) fanden nur langsam Einzug in den Alltag der Entwickler und in der Community, weil die Unterstützung dieser Features häufig an den Abhängigkeiten in einem Projekt und der unterstützten Java-Version scheiterte.

Open-Source-Frameworks und Bibliotheken geraten hingegen unter Druck, wenn sie versuchen, mit der Schlagzahl von Oracle mitzuhalten, ohne sich von dessen kommerziellen Support abhängig zu machen. Sobald die Frameworks neue Sprachfeatures von zukünftigen Versionen verwenden, sind die nicht mehr kompatibel mit älteren Java-Versionen und zwingen sie ihre Projekte ebenfalls auf die aktuelle Java-Version umzustellen.

Abhängigkeit von Oracle?

Die bisherige Betrachtung beschränkt sich auf den Marktführer für Java Virtual Machines (JVM), doch neben Oracle mit dem Oracle JDK beziehungsweise Oracle JRE bieten noch andere Anbieter Laufzeitumgebungen für Java an. Diese Konkurrenzprodukte nutzen allesamt das OpenJDK als Basis.

Das OpenJDK ist der Open-Source-Teil von Java, der auch von Oracle bereitgestellt und in dessen Produkten zum Einsatz kommt. Das OpenJDK enthält alle Bestandteile des Oracle JDKs, um eine Laufzeitumgebung für Java bereitzustellen. Deshalb wird das OpenJDK schon seit längerem in anderen Open-Source-Projekten wie Linux verwendet. Im Vergleich zum Oracle JDK fehlen nur wenige Oracle-spezifische Tools wie etwa der "Java Flight Recorder".

OpenJDK

Die Releases von OpenJDK stehen kostenlos zum Download parat. Der Releasezyklus von OpenJDK entspricht ungefähr dem von Oracle vorgegebenen Zyklus. Ein entscheidender Vorteil von OpenJDK wird in Zukunft sein, dass der kostenlose Support für LTS-Versionen deutlich länger läuft als die von Oracle gewährten sechs Monate.

Das OpenJDK-Projekt bietet kostenlosen Support für Java 11 bis September 2022 an. Oracle wird hingegen für Java 11 bis September 2026 Support gewähren – allerdings nur im Rahmen eines kostenpflichtigen Vertrags. Weitere Informationen zu den geplanten Releases und deren Support sind auf der Seite von OpenJDK zu finden.

Im Zuge der Releaseumstellung von Oracle dürfte sowohl der Bedarf an kommerziellem Support für einzelne Java-Versionen als auch der Markt dafür wachsen. Unter den alternativen Anbietern von Java-Laufzeitumgebungen auf Basis des OpenJDK ist IBM ein gutes Beispiel. Der Konzern bietet ein eigenes JDK für seine Großrechner, Linux- und AIX-Systeme an. Andere Unternehmen haben ihr Geschäftsmodell auf den Support und Vertrieb ihrer Version der Java-Laufzeitumgebung umgestellt – dazu zählt beispielsweise die Firma Azul.

Azul

Aktuell erscheint Azul mit dem Produkt Zulu als ein Unternehmen mit einem viel versprechenden Supportmodell für die Zukunft von Java. Azul bietet zum Einen ein Jahr längeren Support für die LTS-Versionen und schafft zum Anderen einen Kompromiss zwischen den sehr großen LTS-Versionssprüngen und den kurzen halbjährlichen Releasewechseln. Dazu führt Azul die sogenannten Medium-Term-Support-Versionen (MTS) ein, die für jede zweite Java-Version kommerziellen Support von Azul bieten (s. Abb. 3). Die Laufzeiten der MTS-Versionen sind gestaffelt. Azul versucht damit ausreichend Support für eine Migration zur nächsten Version bereitzustellen.

Azul positioniert Zulu hauptsächlich als serverseitige Java-Laufzeitumgebung und verzichtet deshalb auf speziellen Support für Java auf dem Desktop. In Tabelle 3 sind die Preise für den Standard- und den Premium-Support (steht rund um die Uhr zur Verfügung) von Azul ersichtlich. Bei diesem Modell ist die Anzahl der Systeme deutlich einfacher definiert als bei Oracle. Ein System kann ein physischer Server, eine VM, ein Container oder ein Desktop sein. Weiterführende Informationen finden sich auf der Homepage von Azul.

Anzahl Systeme	Standard-Support (pro Jahr)	Premium-Support (pro Jahr )
1-25	$12.000	wird nicht angeboten
16-100	$28.750	$34,500
101-1000	$86.250	$103,500
unbegrenzt	$258.750	$310,500
Tabelle 3: Kommerzielles Supportmodell von Azul

IBM

Zur Unterstützung der eigenen Hardware bietet IBM native JDK-Versionen für AIX, Linux, z/OS und IBM i. Diese Versionen stehen kostenlos zum Download parat. Für Java 7 und 8 liefert IBM weiterhin Sicherheitsupdates und Bugfixes. Weiterführender kommerzieller Support steht für Java-Laufzeitumgebung ebenfalls zur Verfügung.

Bisher hat IBM noch kein Ende der Laufzeit für die Unterstützung von Java 8 bekanntgegeben, aber für Java 7 endet sie im September 2019. Darüber hinaus hat IBM angekündigt, bei dem neuen Releasezyklus von Oracle nicht mehr jede Version von Java zu unterstützen. Das Unternehmen will sich auf das Anbieten der LTS-Versionen konzentrieren. Weiterführende Informationen finden sich auf der Webseite des Java SDK von IBM.

Red Hat

In Red Hat Enterprise Linux 7 unterstützt Red Hat aktuell das OpenJDK 8 und verspricht Support bis 2020. Ähnlich wie IBM will auch Red Hat Java 9 sowie Java 10 überspringen. Die nächste Version in RHEL wird daher OpenJDK 11 sein. Weiterführende Informationen finden sich auf der Webseite von Red Hat.

Fazit

Der neue Releasezyklus bringt verschiedene Herausforderungen für die Anwender von Java, da sich nicht jedes Projekt alle sechs Monate auf eine neue Java-Version migrieren lässt, beziehungsweise nicht jedes Unternehmen dazu bereit und in der Lage ist. Insbesondere Unternehmen mit vielen und umfangreichen Java-Anwendungen müssen die Änderungen und die erforderliche Migrationsstrategie genau planen. Für Drittanbieter von erweitertem Support für ältere Java-Versionen eröffnet sich hingegen ein neuer Markt.

Hendrik Ebbers (@hendrikEbbers)
ist Mitgründer und Senior Software Engineer bei der Karakun AG und lebt in Dortmund. Er ist Java Champion, Mitglied in JSR Expert Groups und Gründer der Java User Group in Dortmund.

Timo Brandstätter
ist Mitgründer und Software Engineer bei der Karakun AG und lebt in Stuttgart. (map)