Seite 2: Warum führt Oracle solche Änderungen ein?

Inhaltsverzeichnis

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.