1. JDK 7 End of Public Updates (EoPU): Was bedeutet das eigentlich?
Das 1×1 des Java-Supports: Wie die Wartung
älterer JDK-Versionen weitergeht
17. Juni 2015 Wolfgang Weigend
(c) shutterstock.com / Georgejmclittle
Seit Mai 2015 sind keine öffentlichen JDK-7-Updates mehr über das Oracle-
Technologienetzwerk (OTN) erhältlich. Das JDK 7 hat damit die so genannte EoPU-Phase (End
of Public Updates) erreicht. Was das bedeutet, und welche Update- bzw. Maintenance-
Regelungen aktuell für Java-Versionen gelten, stellen wir in diesem Artikel dar.
Eines vorweg: Das Erreichen der EoPU-Phase bedeutet nicht, dass keine Updates mehr für ein
JDK erstellt werden. Vielmehr wird die Wartung früherer Java-Versionen innerhalb der Oracle-
Support-Organisation weitergeführt. Damit werden Patch- und Securityupdates für das Oracle
JDK 5, 6, und 7 im Rahmen der jeweiligen technischen Implementierungen erstellt. Der
Download von Java-Critical-Patch-Updates erfolgt dann über das Oracle Java Archive [1].
Öffentlicher JDK-Maintenance-Zyklus
Die öffentliche Verfügbarkeit einer Java-Major-Version ist üblicherweise für den Zeitraum von
ca. 3,5 Jahren vorgesehen. Beispielsweise wurde im Juli 2011 das JDK 7 veröffentlicht. Die
kostenfreien Java-Updates und Java-Critical-Patch-Updates wurden entsprechend bis Ende April
2015 dafür geliefert.
Der Umstieg auf ein neues JDK wird bereits ein Jahr nach dem Erscheinungsdatum eines Java-
Major-Release empfohlen. In diesem Zeitraum können sich die Entwickler mit den neuen
Merkmalen intensiv beschäftigen und die Systemadministratoren können ausgiebig testen, sodass
genügend Erfahrungen zum Umstieg auf eine neue JDK-Version vorliegen sollten. Zudem hat
sich nach zwölf Monaten der Reifegrad des Java-Release meistens noch einmal verbessert.

2. Im aktuellen Fall heißt das: Im März 2014 wurde das JDK
Benachrichtigung für den Zeitpunkt der JDK 7 End of Public Updates (EoPU) zum Ende April
2015 ausgegeben. So konnten sich die Anwender über ein Jahr lang auf einen Umstieg vom
JDK 7 auf das JDK 8 vorbereiten (Tabelle
der Anwendung, die einen JDK-Umstieg nach einem Jahr nicht ermöglichen, so wird empfohlen,
zumindest das aktuelle Java-Critical
mögliche Sicherheitslücken, wie beispielsweise mit dem JDK
Tabelle 1: Java-SE-Public-Updates [5]
EoPU – und danach?
Das JDK 7 ist aktuell also nicht im
durch den Oracle-Java-SE-Support weitergepflegt. So sind auch künftig weitere Java
Sicherheitsupdates erhältlich, vorausgesetzt, es wurde ein Oracle
abgeschlossen. Innerhalb der Oracle
Entwicklungsressourcen angesiedelt, die künftige Java
damit mögliche aufkommende Sicherheitslücken schließen.
Das OpenJDK ist die zentrale Basis zur Erstellung des Oracle
erkannte Sicherheitslücken geschlossen, die Verbesserungen in das aktuelle JDK
eingepflegt und im Rahmen der vorhandenen technischen Konzepte auch in ältere JDK
Versionen (5.0, 6, 7) rückwärtig portiert. Die Auslieferun
JDK 7 und JDK 8 findet zum selben Zeitpunkt statt, wie in der Abbildung
dargestellt.
heißt das: Im März 2014 wurde das JDK 8 veröffentlicht und die
Benachrichtigung für den Zeitpunkt der JDK 7 End of Public Updates (EoPU) zum Ende April
2015 ausgegeben. So konnten sich die Anwender über ein Jahr lang auf einen Umstieg vom
8 vorbereiten (Tabelle 1). Bestehen Abhängigkeiten von der Umgebung und
Umstieg nach einem Jahr nicht ermöglichen, so wird empfohlen,
Critical-Patch-Update im produktiven Betrieb einzusetzen, um
gliche Sicherheitslücken, wie beispielsweise mit dem JDK-7-Update 79, zu schließen.
Updates [5]
und danach?
Das JDK 7 ist aktuell also nicht im End-of-Life-Modus, sondern hat den Status EoPU, und wird
Support weitergepflegt. So sind auch künftig weitere Java
Sicherheitsupdates erhältlich, vorausgesetzt, es wurde ein Oracle-Java-SE-Wartungsvertrag
der Oracle-Java-Support-Organisation sind die
Entwicklungsressourcen angesiedelt, die künftige Java-Critical-Patch-Updates erstellen und
damit mögliche aufkommende Sicherheitslücken schließen.
Das OpenJDK ist die zentrale Basis zur Erstellung des Oracle-JDK. Damit werden einmal
erkannte Sicherheitslücken geschlossen, die Verbesserungen in das aktuelle JDK
eingepflegt und im Rahmen der vorhandenen technischen Konzepte auch in ältere JDK
Versionen (5.0, 6, 7) rückwärtig portiert. Die Auslieferung von Java-Critical-Patch
7 und JDK 8 findet zum selben Zeitpunkt statt, wie in der Abbildung 1 beispielhaft
8 veröffentlicht und die
Benachrichtigung für den Zeitpunkt der JDK 7 End of Public Updates (EoPU) zum Ende April
2015 ausgegeben. So konnten sich die Anwender über ein Jahr lang auf einen Umstieg vom
Bestehen Abhängigkeiten von der Umgebung und
Umstieg nach einem Jahr nicht ermöglichen, so wird empfohlen,
Update im produktiven Betrieb einzusetzen, um
79, zu schließen.
Modus, sondern hat den Status EoPU, und wird
Support weitergepflegt. So sind auch künftig weitere Java-
Wartungsvertrag
Updates erstellen und
K. Damit werden einmal
erkannte Sicherheitslücken geschlossen, die Verbesserungen in das aktuelle JDK-Major-Release
eingepflegt und im Rahmen der vorhandenen technischen Konzepte auch in ältere JDK-
Patch-Updates für
1 beispielhaft

3. Abb. 1: Java-Limited-Updates und Critical
Oracle-Support-Varianten
Der Java-SE-Support erstreckt sich über drei Phasen: Premier Support, Extended Support und
Sustaining Support. Für das Oracle
Extended Support ist bis Juli 2022 erhältlich (Tabelle
dem Erscheinungsdatum des JDK
Eigenschaften in den Oracle-Lifetime
Alerts [3] und die Erstellung von Critical
jedoch ohne weitere Releasezertifizierung für neue Produkte von Drittherstellern und Oracle.
Darüber hinaus kann der Sustaining Support für unbestimmte Zeit ausgewählt werden. Jedoch
verringert sich nach elf Jahren die Fehleranza
Support-Phase keine neuen Critical
Tabelle 2: Oracle-Java-SE-Support
Neben der grundsätzlichen Absicherung mit Java
Java-Critical-Patch-Updates für ältere Java
Anwendungen, die aufgrund von technischen Abhängigkeiten noch mit dem JDK
werden müssen, gegen mögliche Sicherheitsprobleme zu schützen.
Abwärtskompatibilität
Grundsätzlich können ältere Java
ohne kompiliert zu werden mit einer höheren Java
viele JDK-8-Sprachmerkmale erhebliche Vorteile bei der Anwendungsentwicklung und bieten
eine Leistungssteigerung im produktiven Betrieb
Verhindern technische Abhängigkeiten das Upgrade der Java
(JRE 6) auf eine höhere Version, so wird empfohlen, immer die aktuelle Version von Oracle
Java SE 6 für den produktiven Einsatz zu verwenden. Dies entspricht JRE 6 Update 95, mit der
JRE Security Baseline (Full Version String) 1.6.0_9
Versions-Upgrade empfohlen.
Updates und Critical-Patch-Updates für JDK 7 und JDK 8
Varianten
port erstreckt sich über drei Phasen: Premier Support, Extended Support und
Sustaining Support. Für das Oracle-JDK 7 wird der Premier Support bis Juli 2019 angeboten, der
Extended Support ist bis Juli 2022 erhältlich (Tabelle 2). Der Premier Support läuft
dem Erscheinungsdatum des JDK-Major-Release und bietet neben den beschriebenen
Lifetime-Support-Richtlinien [2] auch den Umgang mit Sicherheits
[3] und die Erstellung von Critical-Patch-Updates. Gleiches gilt für den Premier Support,
jedoch ohne weitere Releasezertifizierung für neue Produkte von Drittherstellern und Oracle.
Darüber hinaus kann der Sustaining Support für unbestimmte Zeit ausgewählt werden. Jedoch
verringert sich nach elf Jahren die Fehleranzahl drastisch, und es werden in der Sustaining
Phase keine neuen Critical-Patch-Updates mehr erstellt.
Support-Roadmap
grundsätzlichen Absicherung mit Java-SE-Support [4] ist der Zugang zu künftigen
Updates für ältere Java-Versionen das Hauptargument, um bestehende Java
Anwendungen, die aufgrund von technischen Abhängigkeiten noch mit dem JDK
werden müssen, gegen mögliche Sicherheitsprobleme zu schützen.
Abwärtskompatibilität
Grundsätzlich können ältere Java-Programme durch die gegebene Java-Abwärtskompatibilität
ohne kompiliert zu werden mit einer höheren Java-Version betrieben werden. Jedoch schaffen
Sprachmerkmale erhebliche Vorteile bei der Anwendungsentwicklung und bieten
eine Leistungssteigerung im produktiven Betrieb – weshalb sich ein Upgrade empfiehlt.
Verhindern technische Abhängigkeiten das Upgrade der Java-Runtime-Environment
6) auf eine höhere Version, so wird empfohlen, immer die aktuelle Version von Oracle
Java SE 6 für den produktiven Einsatz zu verwenden. Dies entspricht JRE 6 Update 95, mit der
JRE Security Baseline (Full Version String) 1.6.0_95. Allgemein wird das schrittweise Java
Updates für JDK 7 und JDK 8
port erstreckt sich über drei Phasen: Premier Support, Extended Support und
7 wird der Premier Support bis Juli 2019 angeboten, der
2). Der Premier Support läuft acht Jahre ab
Release und bietet neben den beschriebenen
[2] auch den Umgang mit Sicherheits-
t für den Premier Support,
jedoch ohne weitere Releasezertifizierung für neue Produkte von Drittherstellern und Oracle.
Darüber hinaus kann der Sustaining Support für unbestimmte Zeit ausgewählt werden. Jedoch
hl drastisch, und es werden in der Sustaining-
[4] ist der Zugang zu künftigen
Versionen das Hauptargument, um bestehende Java-
Anwendungen, die aufgrund von technischen Abhängigkeiten noch mit dem JDK 7 betrieben
Abwärtskompatibilität
Jedoch schaffen
Sprachmerkmale erhebliche Vorteile bei der Anwendungsentwicklung und bieten
weshalb sich ein Upgrade empfiehlt.
Environment-Version 6
6) auf eine höhere Version, so wird empfohlen, immer die aktuelle Version von Oracle
Java SE 6 für den produktiven Einsatz zu verwenden. Dies entspricht JRE 6 Update 95, mit der
5. Allgemein wird das schrittweise Java-

4. Die Dokumentation „Java SE 7 and JDK 7 Compatibility“ [6] beschreibt die
Rahmenbedingungen zur Upgradeplanung. Wird eine bestehenden JRE-6-Applikation auf die
nächst höhere Version JRE 7u79 gebracht, so kann dies unter Nutzung des JRE-6-
Kompatibilitätsmodus der JRE 7 geschehen. Java SE 7 ist binär-kompatibel mit Java SE 6. Mit
Ausnahme der dokumentierten Inkompatibilitäten sind die mit dem Java-SE-6-Compiler
erzeugten Klassendateien mit Java SE 7 korrekt ablauffähig.
Im Dokument „Compatibility Guide for JDK 8“ [7] werden drei Bereiche mit potenzieller
Unverträglichkeit in Abhängigkeit vom Java-Plattform-Release beschrieben. Dabei handelt es
sich um die Binär- und die Sourcecode-Kompatibilität sowie das Kompatibilitätsverhalten von
Bibliotheken mit deren Implementierung:
Die Binärkompatibilität ist in der Java-Sprachspezifikation wie folgt definiert: Eine Type-
Änderung ist binärkompatibel mit vorhandenen Binärdateien, wenn diese vorher ohne Fehler
gelinkt wurden und sie fortwährend ohne Fehler gelinkt werden können. Gleichermaßen darf die
Binärkompatibilität mit vorher existierenden Binärdateien nicht gebrochen werden. Java SE 8 ist
binärkompatibel mit Java SE 7. Mit Ausnahme der dokumentierten Inkompatibilitäten sind die
mit dem Java-SE-7-Compiler erzeugten Klassendateien mit Java SE 8 korrekt ablauffähig.
Jedoch sind Klassendateien, die mit Java SE 8 erzeugt wurden, nicht mit früheren Java-SE-
Versionen ablauffähig.
Die Source-Kompatibilität betrifft die Übersetzung von Java-Quellcode in eine Java-
Klassendatei mit durchführbarer Kompilation oder gar nicht kompilierbarem Code. Verwendet
man die neuen Java-SE-8-Sprachmerkmale und Plattform-APIs in einer Source-Datei, so kann
dieser Quellcode nicht mit einer früheren Version der Java-Plattform kompiliert werden.
Allgemein geht es bei der Source-Kompatibilitätsrichtlinie um die Vermeidung der Einführung
von Sourcecode-Unverträglichkeiten. Jedoch erfordert die Implementierung einiger Java-SE-8-
Merkmale Änderungen, die dazu führen, dass ein mit Java SE 7 kompilierter Code nicht mit Java
SE 8 kompiliert werden kann (siehe dokumentierte Inkompatibilitäten zwischen Java SE 8 und
Java SE 7 [8], sowie JDK 8 und JDK 7 [9]). Veraltete APIs dienen nur noch als Schnittstelle zur
Unterstützung der Kompatibilität mit früheren Java-Versionen. Der Kompiler javac erzeugt
Warnmeldungen, wenn veraltete APIs verwendet werden, es sei denn, die Warnungen werden
auf Kommandozeilenebene mit nowarn ausgeschaltet.
Es wird empfohlen, den Java-Programmcode so anzupassen, dass ältere APIs daraus entfernt
werden. Einige APIs in den Paketen sun.* wurden verändert. Diese sollten von den Entwicklern
nicht mehr benutzt werden. Werden sun.*-Pakete weiterhin verwendet, so geschieht dies unter
einem hohen Risiko [4] [9].
Das Kompatibilitätsverhalten (Behavioral Compatibility) beinhaltet die Semantik von Java-
Code, der zur Laufzeit ausgeführt wird. Mit identischen Programmeingaben wird dieselbe oder
eine vergleichbare Operation mit unterschiedlichen Versionen von Bibliotheken oder der
Plattform durchgeführt. Einige Aspekte, die das Plattformverhalten bestimmen, sind bewusst
unspezifiziert, und die darunterliegende technische Implementierung kann sich in einem
Plattformrelease verändern. Aus diesem Grund muss der Code so geschrieben worden sein, dass

5. er nicht vom unspezifizierten Verhalten abhängig ist. Falls doch, wäre ein aufgetretenes Problem
keine Plattformunverträglichkeit, sondern ein Kodierungsfehler im JDK.
Fazit
Die Erfahrungen beim Umstieg von JDK 6 nach JDK 7 haben gezeigt, dass die Variante 1: „Just
run“ praktisch nutzbar ist [6]. D.h. existierende Java-Anwendungen sind dank
Abwärtskompatibilität ohne Modifikation mit dem höheren Java-Release ablauffähig. Denoch
muß man in seltenen Fällen die Möglichkeit einer Unverträglichkeit in Betracht ziehen, wenn
auch nur in Randbereichen.
Mit der Variante 2 „Neukompilieren und Quellcode anpassen“ wird der alte Java-Code immer
auf dem aktuellen Stand der Technik gehalten und durch die gängigen Entwicklungsumgebungen
bestmöglich unterstützt.
Nach verschiedenen Befragungen innerhalb der Java Community ist ein positiver Trend beim
Umstieg auf das JDK 8 zu erkennen, der aktuell bei ca. 25% liegt. Die Anzahl von JDK-8-
Umsteigern ist größer, als dies bisher bei den vorangegangenen JDKs der Fall war. Der Umstieg
auf das aktuelle JDK 8 bringt den Vorteil einer ausgereiften und modernen Anwendungs-Code-
Struktur mit innovativer Technologie. Alternativ können Java-Anwendungen weiterhin mit JDK
7 betrieben werden. Man sollte sich aber die Frage stellen, ob die Produktivumgebungen ohne
eine Support-Absicherung den künftigen Sicherheitsanforderungen standhalten können. Es ist
ratsam, die betroffenen Java-SE-7-Anwendungen mit dem Java SE Support auszustatten, um
weitere Sicherheit-Patches & Java Critical Patch Updates im Produlktivbetrieb so lange
einspielen zu können, bis ein Umstieg auf das JDK 8 vollzogen werden kann. Von Oracle wird
immer das frei verfügbare JDK, derzeit das JDK 8, mit dem letzten Java Critical Patch Update
für den produktiven Einsatz empfohlen.
Aufmacherbild: render of gears and the text java von Shutterstock.com /
Urheberrecht: Georgejmclittle
Links & Literatur
[1] http://www.oracle.com/technetwork/java/javase/archive-139210.html
[2] http://www.oracle.com/us/support/lifetime-support-068561.html
[3] http://www.oracle.com/technetwork/topics/security/alerts-086861.html
[4] http://www.oracle.com/technetwork/java/faq-sun-packages-142232.html
[5] http://www.oracle.com/technetwork/java/eol-135779.html
[6] http://www.oracle.com/technetwork/java/javase/compatibility-417013.html
[7] http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html

6. [8] http://www.oracle.com/technetwork/java/javas
2156366.html#A999198
[9] http://www.oracle.com/technetwork/java/javase/8
2156366.html#A999387
[10] https://blogs.oracle.com/henrik/entry/migrating_from_java_se_6
[11] http://www.oracle.com/technetwork/java/javase/8
2156366.html#A1000033
[12] http://www.oracle.com/us/technologies/java/standard
Geschrieben von
Wolfgang Weigend
Wolfgang Weigend arbeitet als Sen. Leitender Systemberater bei der Oracle Deutschland B.V. &
Co. KG. Er beschäftigt sich mit Java
Anwendungsentwicklung.
https://jaxenter.de/das-1x1-des-java
weitergeht-21309
http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-
http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-
ttps://blogs.oracle.com/henrik/entry/migrating_from_java_se_6
http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-
http://www.oracle.com/us/technologies/java/standard-edition/support/overview/index.html
Wolfgang Weigend arbeitet als Sen. Leitender Systemberater bei der Oracle Deutschland B.V. &
Co. KG. Er beschäftigt sich mit Java-Technologie und -Architektur für unternehmensweite
java-supports-wie-die-wartung-aelterer-jdk-versionen
edition/support/overview/index.html
Wolfgang Weigend arbeitet als Sen. Leitender Systemberater bei der Oracle Deutschland B.V. &
Architektur für unternehmensweite
versionen-