JDK 7 End of Public Updates (EoPU): Was bedeutet das eigentlich?
Das 1×1 des Java-Supports: Wie die Wartung
älterer JDK-Ve...
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...
Abb. 1: Java-Limited-Updates und Critical
Oracle-Support-Varianten
Der Java-SE-Support erstreckt sich über drei Phasen: Pr...
Die Dokumentation „Java SE 7 and JDK 7 Compatibility“ [6] beschreibt die
Rahmenbedingungen zur Upgradeplanung. Wird eine b...
er nicht vom unspezifizierten Verhalten abhängig ist. Falls doch, wäre ein aufgetretenes Problem
keine Plattformunverträgl...
[8] http://www.oracle.com/technetwork/java/javas
2156366.html#A999198
[9] http://www.oracle.com/technetwork/java/javase/8
...
Nächste SlideShare
Wird geladen in …5
×

Das 1×1 des java supports wie die wartung älterer jdk-versionen weitergeht

273 Aufrufe

Veröffentlicht am

0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
273
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
13
Aktionen
Geteilt
0
Downloads
1
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Das 1×1 des java supports wie die wartung älterer jdk-versionen weitergeht

  1. 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. 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. 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. 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. 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. 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-

×