Java 8-Releaseänderungen

Java 8-Releasehauptmerkmale

Dieser Artikel gilt für:

Plattform(en): Keine
Browser: Keine
Java version(en): 8.0

Auf dieser Seite werden die Änderungen hervorgehoben, die bei jedem Java-Release die Endbenutzer betreffen. Weitere Informationen zu den Änderungen finden Sie in den Releasehinweisen für jedes Release.
» Java-Releasedaten

Java 8 Update 441 (8u441)

Releasehauptmerkmale

JDK 8u441 enthält IANA-Zeitzonendaten der Version 2024b.
Weitere Informationen finden Sie unter Versionen von Zeitzonendaten in der JRE-Software.
JavaFX ist in Zukunft nicht mehr in JDK/JRE 8 enthalten
Dieses Release, JDK und JRE 8 Update 441, ist das letzte Release mit JavaFX. Wie 2020 angekündigt wird die Unterstützung für JavaFX auf JDK 8, der letzten kommerziell unterstützten JavaFX-Version von Oracle, im März 2025 eingestellt. Daher ist JDK 8 Update 441 das letzte Upgrade von JDK/JRE 8 mit JavaFX. Oracle entwickelt und veröffentlicht JavaFX weiterhin in Form von Standalone-Modulen über das OpenJFX-Projekt für die neuesten Java-Versionen. Weitere Details dazu finden Sie unter Java SE Spring 2024 Roadmap Update.
Weitere Hinweise: Unterstützung für Zeitzonendatenbank 2024b
Die IANA-Zeitzonendatenbank wurde auf 2024b upgegradet. Diese Version umfasst in erster Linie Änderungen zur Verbesserung von historischen Daten für Mexiko, die Mongolei und Portugal. Außerdem wird darin eine Zeitzonenabkürzung für die Zeitzone "MET" geändert. Außerdem ist Asia/Choibalsan jetzt ein Alias für Asia/Ulaanbaatar.
Siehe JDK-8339637

JDK auf dem aktuellen Stand halten

Oracle empfiehlt, das JDK mit jedem kritischen Patchupdate zu aktualisieren. Auf der Seite Sicherheitsbaseline können Sie die aktuelle Version für jede Releasefamilie bestimmen.

Kritische Patchupdates, die Sicherheitslücken beheben, werden ein Jahr im Voraus unter "Critical Patch Updates, Security Alerts and Bulletins" bekannt gegeben. Es wird nicht empfohlen, dieses JDK (Version 8u441) nach dem nächsten kritischen Patchupdate zu verwenden. Dieses ist für den 15. April 2025 geplant.

Java Management Service ist für alle Benutzer verfügbar und kann Ihnen dabei helfen, anfällige Java-Versionen in Ihren Systemen zu ermitteln. Java SE-Abonnenten und Kunden auf Oracle Cloud können Java Management Service verwenden, um JREs zu aktualisieren und weitere Sicherheitsprüfungen auszuführen, wie die Identifizierung potenziell anfälliger Drittanbieter-Librarys, die von Ihren Java-Programmen genutzt werden. Aktuelle Benutzer von Java Management Service klicken hier, um sich beim Dashboard anzumelden. In der Java Management Service-Dokumentation finden Sie eine Liste der Features, die für alle Personen verfügbar sind, und derjenigen, auf die nur Kunden zugreifen können. Erfahren Sie mehr über Java Management Service und das Monitoring und die Sicherung Ihrer Java-Installationen.

Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u441) auf Basis eines alternativen Mechanismus am 15. Mai 2025 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren. Weitere Informationen finden Sie unter Ablaufdatum für 23.1.2 JRE im Deployment-Handbuch für Java Platform, Standard Edition.

Bugfixes

Dieses Release enthält Fixes zum Schließen von Sicherheitslücken. Weitere Informationen finden Sie in Oracle - Kritisches Patchupdate. Eine Liste der in diesem Release enthaltenen Bugfixes finden Sie in den 8u441-Versionshinweisen.

Java 8 Update 431 (8u431)

Releasehauptmerkmale

JDK 8u431 enthält IANA-Zeitzonendaten der Version 2024a.
Weitere Informationen finden Sie unter Versionen von Zeitzonendaten in der JRE-Software.
Erwähnenswerte behobene Probleme: JDK-RPM-Upgrade hinterlässt verwaisten Alternativeintrag
Das Problem, dass Einträge in den Gruppen "java" und "javac" bei einem RPM-Upgrade nicht korrekt verwaltet werden, wurde behoben.
Beim Upgrade von einem älteren Java-RPM, das in einem gemeinsamen Verzeichnis installiert ist (/usr/lib/jvm/jdk-${FEATURE}-oracle-${ARCH}), auf eine Java-RPM-Installation mit einem versionsspezifischen Verzeichnis (/usr/lib/jvm/jdk-${VERSION}-oracle-${ARCH}) werden ältere Java-Einträge in den Gruppen "java" und "javac" nicht gelöscht.
JDK-8336107 (nicht allgemein zugänglich)
Weitere Hinweise: Neue Standardgrenzwerte in den JDK-HTTP-Implementierungen
Neue Standardgrenzwerte wurden zu HTTP im JDK hinzugefügt.
Die integrierte JDK-Implementierung des URL-Protokoll-Handlers für HTTP (HttpURLConnection) beinhaltet jetzt einen Standardgrenzwert für die maximale Antwortheadergröße, die von einer Remotepartei akzeptiert wird. Der Grenzwert wird standardmäßig auf 384 KB (393216 Byte) gesetzt und als kumulative Größe aller Headernamen und -werte plus Overhead von 32 Byte pro Headername/Headerwert-Paar berechnet.
JDK-8328286 (nicht allgemein zugänglich)
Weitere Hinweise: TLS-Root-CA-Zertifikate von SSL.com hinzugefügt, die 2022 ausgestellt wurden
Die folgenden Root-Zertifikate wurden dem cacerts-Truststore hinzugefügt:
+ SSL.com
+ ssltlsrootecc2022
DN: CN=SSL.com TLS ECC Root CA 2022, O=SSL Corporation, C=US
+ SSL.com
+ ssltlsrootrsa2022
DN: CN=SSL.com TLS RSA Root CA 2022, O=SSL Corporation, C=US
Siehe JDK-8341057
Weitere Hinweise: Über Entrust-Root-Zertifikate verankerte TLS-Serverzertifikate, die nach dem 11. November 2024 ausgestellt werden, werden nicht mehr als vertrauenswürdig eingestuft
Von Entrust-Root-Zertifikaten verankerte TLS-Serverzertifikate, die nach dem 11. November 2024 ausgestellt werden, werden von JDK nicht mehr als vertrauenswürdig eingestuft, entsprechend ähnlichen Plänen, die vor Kurzem von Google und Mozilla angekündigt wurden. Die Liste der betroffenen Zertifikate beinhaltet Zertifikate mit AffirmTrust-Branding, die von Entrust verwaltet werden.
Siehe JDK-8337664

JDK auf dem aktuellen Stand halten

Oracle empfiehlt, das JDK mit jedem kritischen Patchupdate zu aktualisieren. Auf der Seite Sicherheitsbaseline können Sie die aktuelle Version für jede Releasefamilie bestimmen.

Kritische Patchupdates, die Sicherheitslücken beheben, werden ein Jahr im Voraus unter "Critical Patch Updates, Security Alerts and Bulletins" bekannt gegeben. Es wird nicht empfohlen, dieses JDK (Version 8u431) nach dem nächsten kritischen Patchupdate zu verwenden. Dieses ist für den 21. Januar 2025 geplant.

Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u431) auf Basis eines alternativen Mechanismus am 21. Februar 2025 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren. Weitere Informationen finden Sie unter Ablaufdatum für 23.1.2 JRE im Deployment-Handbuch für Java Platform, Standard Edition.

Bugfixes

Java 8 Update 421 (8u421)

Releasehauptmerkmale

JDK 8u421 enthält IANA-Zeitzonendaten der Version 2024a.
Weitere Informationen finden Sie unter Versionen von Zeitzonendaten in der JRE-Software.
Bekanntes Problem: Verwendung des Browser-Keystores unter Windows
Wenn unter Windows das Feature "Zertifikate und Schlüssel in Browser-Keystore verwenden" aktiviert ist (was standardmäßig der Fall ist), können Java WebStart und das Java-Plug-in auf die Zertifikate zugreifen, die derzeit vertrauenswürdig für den lokalen Rechner sind. Da die Zertifikate dynamisch geladen werden, kann nicht garantiert werden, dass die vollständige Liste vertrauenswürdiger Zertifikate verfügbar ist. Daher können bei Java-Applets und Java WebStart-Anwendungen Probleme mit der Signaturvalidierung und mit sicheren Verbindungen aufgrund fehlender relevanter Zertifikate auftreten, da das Deployment-Framework nur auf die Zertifikate zugreifen kann, die zum Zeitpunkt des Anwendungsstarts "aktiv" sind.
JDK-8330728 (nicht allgemein zugänglich)
Weitere Hinweise: Hinzufügen des Arguments STATIC=1 zum JRE-Installationsprogramm
Durch diesen Fix wird das Installationsprogrammargument STATIC=1 hinzugefügt und das Installationsprogrammargument RETAIN_ALL_VERSIONS=1 eingestellt. Durch Übergabe von STATIC=1 wird verhindert, dass ältere JRE 8-Versionen bei einem manuellen Upgrade oder automatischen Update deinstalliert werden.
JDK-8313223 (nicht allgemein zugänglich)
Weitere Hinweise: Root-CA-Zertifikate GlobalSign R46 und E46 hinzugefügt
Die folgenden Root-Zertifikate wurden dem cacerts-Truststore hinzugefügt:
+ GlobalSign + globalsignr46 DN: CN=GlobalSign Root R46, O=GlobalSign nv-sa, C=BE + GlobalSign + globalsigne46 DN: CN=GlobalSign Root E46, O=GlobalSign nv-sa, C=BE
Siehe JDK-8316138
Weitere Hinweise: Installationsprogramm erstellt ein Junction-Verzeichnis in einem neuen Speicherort
Die JRE wird im folgenden Speicherort installiert: C:\Program Files\Java\latest\jre-$fullversion. Dabei ist $fullversion die technische Version der JRE. Beispiel: 8u421 wird in C:\Program Files\Java\latest\jre-1.8.0_421 installiert.

Für Java der 32-Bit-Version wird "C:\Program Files" in "C:\Program Files (x86)" geändert.

Eine Junction wird unter C:\Program Files\Java\latest\jre-1.8 erstellt. Sie zeigt auf die neueste JRE der Familie 8.
JDK-8329700 (nicht allgemein zugänglich)

JDK auf dem aktuellen Stand halten

Oracle empfiehlt, das JDK mit jedem kritischen Patchupdate zu aktualisieren. Auf der Seite Sicherheitsbaseline können Sie die aktuelle Version für jede Releasefamilie bestimmen.

Kritische Patchupdates, die Sicherheitslücken beheben, werden ein Jahr im Voraus unter "Critical Patch Updates, Security Alerts and Bulletins" bekannt gegeben. Es wird nicht empfohlen, dieses JDK (Version 8u421) nach dem nächsten kritischen Patchupdate zu verwenden. Dieses ist für den 15. Oktober 2024 geplant.

Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u421) auf Basis eines alternativen Mechanismus am 15. November 2024 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren. Weitere Informationen finden Sie unter Ablaufdatum für 23.1.2 JRE im Deployment-Handbuch für Java Platform, Standard Edition.

Bugfixes

Java 8 Update 411 (8u411)

Releasehauptmerkmale

JDK 8u411 enthält IANA-Zeitzonendaten der Version 2024a.
Weitere Informationen finden Sie unter Versionen von Zeitzonendaten in der JRE-Software.
Neues Feature: Root-Zertifikate Certainly R1 und E1 hinzugefügt
Die folgenden Root-Zertifikate wurden dem cacerts-Truststore hinzugefügt:+ Certainly + certainlyrootr1 DN: CN=Certainly Root R1, O=Certainly, C=US + Certainly + certainlyroote1 DN: CN=Certainly Root E1, O=Certainly, C=US
Siehe JDK-8321408
Neues Feature: Sicherer Validierungsmodus für XML-Signaturen standardmäßig aktiviert
Der sichere Validierungsmodus für XML-Signaturen wurde standardmäßig aktiviert (zuvor war er außer bei der Ausführung mit einem Sicherheitsmanager nicht standardmäßig aktiviert). Wenn diese Option aktiviert ist, werden Algorithmen und andere Constraints wie von der Sicherheitseigenschaft jdk.xml.dsig.secureValidationPolicy angegeben bei der Validierung von XML-Signaturen strenger geprüft.
Auf eigenes Risiko können Anwendungen den Modus gegebenenfalls deaktivieren, indem sie die Eigenschaft org.jcp.xml.dsig.secureValidation mit der API DOMValidateContext.setProperty() auf Boolean.FALSE setzen.
Siehe JDK-8259801

JDK auf dem aktuellen Stand halten

Oracle empfiehlt, das JDK mit jedem kritischen Patchupdate zu aktualisieren. Auf der Seite Sicherheitsbaseline können Sie die aktuelle Version für jede Releasefamilie bestimmen.

Kritische Patchupdates, die Sicherheitslücken beheben, werden ein Jahr im Voraus unter "Critical Patch Updates, Security Alerts and Bulletins" bekannt gegeben. Es wird nicht empfohlen, dieses JDK (Version 8u411) nach dem nächsten kritischen Patchupdate zu verwenden. Dieses ist für den 16. Juli 2024 geplant.

Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u411) auf Basis eines alternativen Mechanismus am 16. August 2024 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren. Weitere Informationen finden Sie unter Ablaufdatum für 23.1.2 JRE im Deployment-Handbuch für Java Platform, Standard Edition.

Bugfixes

Java 8 Update 401 (8u401)

Releasehauptmerkmale

JDK 8u401 enthält IANA-Zeitzonendaten der Version 2023c.
Weitere Informationen finden Sie unter Versionen von Zeitzonendaten in der JRE-Software.
Neues Feature: Neue Systemeigenschaft zum Umschalten des sicheren Validierungsmodus für XML-Signaturen
Eine neue Systemeigenschaft namens org.jcp.xml.dsig.secureValidation wurde hinzugefügt. Sie kann verwendet werden, um den sicheren Validierungsmodus für XML-Signaturen zu aktivieren oder zu deaktivieren. Sie können die Systemeigenschaft auf "true" setzen, um den Modus zu aktivieren, oder auf "false", um den Modus zu deaktivieren. Alle anderen Werte für die Systemeigenschaft werden wie "false" behandelt. Wenn die Systemeigenschaft festgelegt ist, ersetzt sie den Eigenschaftswert XMLCryptoContext. Der sichere Validierungsmodus ist standardmäßig aktiviert, wenn Sie den Code mit einem SecurityManager ausführen. Andernfalls ist er standardmäßig deaktiviert.
Siehe JDK-8301260
Neues Feature: JDK Flight Recorder-Ereignis für die Deserialisierung
Ein neues JDK Flight Recorder-(JFR-)Ereignis zur Überwachung der Deserialisierung von Objekten wurde hinzugefügt. Wenn JFR aktiviert ist und die JFR-Konfiguration Deserialisierungsereignisse enthält, gibt JFR immer dann ein Ereignis aus, wenn das ausgeführte Programm versucht, ein Objekt zu deserialisieren. Das Deserialisierungsereignis trägt den Namen java/deserialization und ist standardmäßig deaktiviert. Das Deserialisierungsereignis enthält Informationen, die vom Serialisierungsfiltermechanismus verwendet werden. Wenn ein Filter aktiviert ist, gibt das JFR-Ereignis außerdem an, ob der Filter die Deserialisierung des Objekts akzeptiert oder abgelehnt hat.
Siehe JDK-8261160

JDK auf dem aktuellen Stand halten

Oracle empfiehlt, das JDK mit jedem kritischen Patchupdate zu aktualisieren. Auf der Seite Sicherheitsbaseline können Sie die aktuelle Version für jede Releasefamilie bestimmen.

Kritische Patchupdates, die Sicherheitslücken beheben, werden ein Jahr im Voraus unter "Critical Patch Updates, Security Alerts and Bulletins" bekannt gegeben. Es wird nicht empfohlen, dieses JDK (Version 8u401) nach dem nächsten kritischen Patchupdate zu verwenden. Dieses ist für den 16. April 2024 geplant.

Kunden von Java SE-Abonnementprodukten, die JRE-Updates/-Installationen für eine große Anzahl an Desktops verwalten, sollten die Verwendung des Java Management Service (JMS) in Erwägung ziehen.

Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u401) auf Basis eines alternativen Mechanismus am 16. Mai 2024 ab. Wenn eine der beiden Bedingungen erfüllt wird (neues Release wird verfügbar/Ablaufdatum erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren. Weitere Informationen finden Sie unter Ablaufdatum für 23.1.2 JRE im Deployment-Handbuch für Java Platform, Standard Edition.

Bugfixes

Java 8 Update 391 (8u391)

Releasehauptmerkmale

JDK 8u391 enthält IANA-Zeitzonendaten der Version 2023c.
Weitere Informationen finden Sie unter Versionen von Zeitzonendaten in der JRE-Software.
Neues Feature: Neues JFR-Ereignis: jdk.SecurityProviderService
Ein neues Java Flight Recorder-(JFR-)Ereignis wurde hinzugefügt, um Details von java.security.Provider.getService(String type, String algorithm)-Aufrufen aufzuzeichnen.
Siehe JDK-8254711
Entferntes Feature: RootCA1-Root-Zertifikat von SECOM Trust System wurde entfernt
Das folgende Root-Zertifikat von SECOM Trust System wurde aus dem cacerts-Keystore entfernt:
+ alias name "secomscrootca1 [jdk]" Distinguished Name: OU=Security Communication RootCA1, O=SECOM Trust.net, C=JP
Siehe JDK-8295894
Entferntes Feature: Linux ARM32-Unterstützung für JDK 8 entfernt
Plattformunterstützung für Linux ARM32 wurde in JDK 8 entfernt. Daher ist der ARM32 Hard Float ABI-Download nicht verfügbar. Betriebssysteme, die ARM32 unterstützten, haben ihr Lebensdauerende erreicht. Daher ist keine bekannte BS-Unterstützung verfügbar.
JDK-8305927 (nicht allgemein zugänglich)
Weitere Hinweise: Certigna-Root-Zertifikat hinzugefügt
Das folgende Root-Zertifikat wurde dem cacerts-Truststore hinzugefügt:
+ Certigna (Dhimyotis) + certignarootca DN: CN=Certigna Root CA, OU=0002 48146308100036, O=Dhimyotis, C=FR
Siehe JDK-8314960

JDK auf dem aktuellen Stand halten

Oracle empfiehlt, das JDK mit jedem kritischen Patchupdate zu aktualisieren. Auf der Seite Sicherheitsbaseline können Sie die aktuelle Version für jede Releasefamilie bestimmen.

Kritische Patchupdates, die Sicherheitslücken beheben, werden ein Jahr im Voraus unter "Critical Patch Updates, Security Alerts and Bulletins" bekannt gegeben. Es wird nicht empfohlen, dieses JDK (Version 8u391) nach dem nächsten kritischen Patchupdate zu verwenden. Dieses ist für den 16. Januar 2024 geplant.

Kunden des Java SE-Abonnements, die JRE-Updates/-Installationen für eine große Anzahl an Desktops verwalten, sollten die Verwendung der Java Advanced Management Console (AMC) in Erwägung ziehen.

Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u391) auf Basis eines alternativen Mechanismus am 16. Februar 2024 ab. Wenn eine der beiden Bedingungen erfüllt ist (eine neue Version wird verfügbar oder das Ablaufdatum ist erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren. Weitere Informationen finden Sie unter Ablaufdatum für 23.1.2 JRE im Deployment-Handbuch für Java Platform, Standard Edition.

Bugfixes

Java 8 Update 381 (8u381)

Releasehauptmerkmale

JDK 8u381 enthält IANA-Zeitzonendaten der Version 2023c.
Weitere Informationen finden Sie unter Versionen von Zeitzonendaten in der JRE-Software.
Neues Feature: Zusätzliche Zeichen für GB18030-2022-Unterstützung zulassen
Die China National Standard-Behörde (CESI) hat vor Kurzem GB18030-2022 veröffentlicht, eine aktualisierte Version des GB18030-Standards, die GB18030 mit Unicode Version 11.0 in Einklang bringt. Die Zeichensatzimplementierung für diesen neuen Standard hat jetzt den vorherigen 2000-Standard ersetzt. Dieser neue Standard bringt allerdings einige inkompatible Änderungen gegenüber der vorherigen Implementierung mit sich. Für Personen, die die alten Zuordnungen verwenden müssen, wird die neue Systemeigenschaft jdk.charset.GB18030 eingeführt. Wenn Sie deren Wert auf "2000" setzen, werden die Zuordnungen der vorherigen JDK-Releases für den GB18030-Zeichensatz verwendet, die auf dem 2000-Standard basieren.
Siehe JDK-8307229
JDK akzeptiert jetzt RSA-Schlüssel im PKCS#1-Format
RSA-Private-Keys und -Public-Keys im PKCS#1-Format können jetzt von JDK-Providern akzeptiert werden, darunter RSA KeyFactory.impl vom SunRsaSign-Provider. Das RSA-Private-Key- oder -Public-Key-Objekt muss das PKCS#1-Format und eine Codierung entsprechend der ASN.1-Syntax für einen RSA-Private-Key und -Public-Key im PKCS#1-Format aufweisen.
Siehe JDK-8023980
Weitere Hinweise: Unterstützung und Verbesserungen von cgroup v2 in 8u381
JDK 8u381 umfasst mehrere Verbesserungen und Fixes für die Unterstützung von cgroup v1 und v2 für Container. Zu den Verbesserungen gehören die korrekte Erkennung der Ressourcenlimits von Containern, die richtige Meldung der erfassten Containermetriken, das Ausgeben zusätzlicher Containerinformationen und das Verbessern der Anwendungsstabilität in containerisierten Umgebungen.
Siehe JDK-8307634
Weitere Hinweise: TWCA-Root-CA-Zertifikat hinzugefügt
Das folgende Root-Zertifikat wurde dem cacerts-Truststore hinzugefügt:
+ TWCA + twcaglobalrootca DN: CN=TWCA Global Root CA, OU=Root CA, O=TAIWAN-CA, C=TW
Siehe JDK-8305975
Weitere Hinweise: 4 GTS-Root-CA-Zertifikate hinzugefügt
Die folgenden Root-Zertifikate wurden dem cacerts-Truststore hinzugefügt:
+ Google Trust Services LLC + gtsrootcar1 DN: CN=GTS Root R1, O=Google Trust Services LLC, C=US + Google Trust Services LLC + gtsrootcar2 DN: CN=GTS Root R2, O=Google Trust Services LLC, C=US + Google Trust Services LLC + gtsrootecccar3 DN: CN=GTS Root R3, O=Google Trust Services LLC, C=US + Google Trust Services LLC + gtsrootecccar4 DN: CN=GTS Root R4, O=Google Trust Services LLC, C=US
Siehe JDK-8307134
Weitere Hinweise: 2 TLS-Root-CA-Zertifikate von Microsoft Corporation hinzugefügt
Die folgenden Root-Zertifikate wurden dem cacerts-Truststore hinzugefügt:
+ Microsoft Corporation + microsoftecc2017 DN: CN=Microsoft ECC Root Certificate Authority 2017, O=Microsoft Corporation, C=US + Microsoft Corporation + microsoftrsa2017 DN: CN=Microsoft RSA Root Certificate Authority 2017, O=Microsoft Corporation, C=US
Siehe JDK-8304760

JDK auf dem aktuellen Stand halten

Oracle empfiehlt, das JDK mit jedem kritischen Patchupdate zu aktualisieren. Auf der Seite Sicherheitsbaseline können Sie die aktuelle Version für jede Releasefamilie bestimmen.

Kritische Patchupdates, die Sicherheitslücken beheben, werden ein Jahr im Voraus unter "Critical Patch Updates, Security Alerts and Bulletins" bekannt gegeben. Es wird nicht empfohlen, dieses JDK (Version 8u381) nach dem nächsten kritischen Patchupdate zu verwenden. Dieses ist für den 17. Oktober 2023 geplant.

Kunden des Java SE-Abonnements, die JRE-Updates/-Installationen für eine große Anzahl an Desktops verwalten, sollten die Verwendung der Java Advanced Management Console (AMC) in Erwägung ziehen.

Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u381) auf Basis eines alternativen Mechanismus am 17. November 2023 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren. Weitere Informationen finden Sie unter Ablaufdatum für 23.1.2 JRE im Deployment-Handbuch für Java Platform, Standard Edition.

Bugfixes

Java 8 Update 371 (8u371)

Releasehauptmerkmale

JDK 8u371 enthält IANA-Zeitzonendaten der Version 2022g.
Weitere Informationen finden Sie unter Versionen von Zeitzonendaten in der JRE-Software.
Neues Feature: Native Standard-GSS-API-Library unter Windows hinzugefügt
Eine native GSS-API-Library wurde JDK auf der Windows-Plattform hinzugefügt. Die Library gilt nur für die Clientseite und verwendet die Standardzugangsdaten. Sie wird geladen, wenn die Systemeigenschaft sun.security.jgss.native auf "true" gesetzt ist. Benutzer können weiterhin eine native GSS-API-Library eines Drittanbieters laden, indem sie die Systemeigenschaft sun.security.jgss.lib auf den jeweiligen Pfad setzen.
Siehe JDK-6722928
Entfernte Features und Optionen: javax.script-Engine-Implementierung und com.apple.concurrent.Dispatch wurden für macOS AArch64 entfernt
Die AppleScript-Engine, die die javax.script-Engine-API implementiert, wurde ersatzlos entfernt. Die AppleScript-Engine hat nicht konsistent funktioniert. Die Servicekonfigurationsdatei (META-INF/services) hat gefehlt und funktionierte nur zufällig, wenn JDK 7 oder JDK 8 auf Systemen installiert wurde, auf denen die Apple-Version von AppleScriptEngine.jar bereits installiert war.
Die com.apple.concurrent.Dispatch-API war nur für Mac verfügbar. Sie wurde mit der Portierung des JDK 6-Codes von Apple in JDK 7u4 übertragen. Es wird empfohlen, dass Entwickler stattdessen die Standard-APIs java.util.concurrent.Executor und java.util.concurrent.ExecutorService verwenden.
Siehe JDK-8297475
Weitere Hinweise: Certigna(Dhimyotis)-Root-CA-Zertifikat hinzugefügt
Das folgende Root-Zertifikat wurde dem cacerts-Truststore hinzugefügt:
+ Certigna (Dhimyotis) + certignarootca DN: CN=Certigna, O=Dhimyotis, C=FR
Siehe JDK-8245654
Weitere Hinweise: SSLv2Hello und SSLv3 wurden von den standardmäßig aktivierten TLS-Protokollen entfernt
SSLv2Hello und SSLv3 wurden von den standardmäßig aktivierten TLS-Protokollen entfernt.

Wenn Sie nach diesem Update SSLv3 von der Sicherheitseigenschaft jdk.tls.disabledAlgorithms entfernen, geben die APIs SSLSocket.getEnabledProtocols(), SSLServerSocket.getEnabledProtocols(), SSLEngine.getEnabledProtocols() und SSLParameters.getProtocols() "TLSv1.3, TLSv1.2, TLSv1.1, TLSv1" zurück. "SSLv3" wird in dieser Liste nicht zurückgegeben.
Wenn ein Client oder Server das SSLv3-Protokoll verwenden muss, kann er dazu die Systemeigenschaft jdk.tls.client.protocols oder jdk.tls.server.protocols aktivieren oder die APIs SSLSocket.setEnabledProtocols(), SSLServerSocket.setEnabledProtocols() und SSLEngine.setEnabledProtocols() verwenden.
Siehe JDK-8190492

JDK auf dem aktuellen Stand halten

Oracle empfiehlt, das JDK mit jedem kritischen Patchupdate zu aktualisieren. Auf der Seite Sicherheitsbaseline finden Sie die aktuelle Version für jede Releasefamilie.

Kritische Patchupdates, die Sicherheitslücken beheben, werden ein Jahr im Voraus unter Critical Patch Updates, Security Alerts and Bulletins bekannt gegeben. Es wird nicht empfohlen, dieses JDK (Version 8u371) nach dem nächsten kritischen Patchupdaterelease zu verwenden. Dieses ist für den 18. Juli 2023 geplant.

Kunden des Java SE-Abonnements, die JRE-Updates/-Installationen für eine große Anzahl an Desktops verwalten, sollten die Verwendung der Java Advanced Management Console (AMC) in Erwägung ziehen.

Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u371) auf Basis eines alternativen Mechanismus am 18. August 2023 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren. Weitere Informationen finden Sie unter Ablaufdatum für 23.1.2 JRE im Deployment-Handbuch für Java Platform, Standard Edition.

Bugfixes

Java 8 Update 361 (8u361)

Releasehauptmerkmale

JDK 8u361 enthält IANA-Zeitzonendaten der Versionen 2022d, 2022e, 2022f.
Weitere Informationen finden Sie unter Versionen von Zeitzonendaten in der JRE-Software.
Neues Feature: Unterstützung für RSASSA-PSS in der OCSP-Antwort
Mit dem RSASSA-PSS-Algorithmus signierte OCSP-Antworten werden jetzt unterstützt.
Siehe JDK-8274471
Weitere Hinweise: FXML-JavaScript-Engine standardmäßig deaktiviert
Die "JavaScript-Skript-Engine" für FXML ist jetzt standardmäßig deaktiviert. FXML-Dateien mit einer "javascript"-Verarbeitungsanweisung werden standardmäßig nicht mehr geladen, und eine Ausnahme wird ausgelöst.
Die Engine kann durch Setzen folgender Systemeigenschaft aktiviert werden: -Djavafx.allowjs=true
JDK-8294779 (nicht allgemein zugänglich)
Weitere Hinweise: Falsches Handling von Argumenten in Anführungszeichen in ProcessBuilder
ProcessBuilder unter Windows wurde wiederhergestellt, um ein von JDK-8250568 verursachtes Regressionsproblem zu beheben. Zuvor wurde ein Argument für ProcessBuilder, das mit doppelten Anführungszeichen begann und mit einem umgekehrten Schrägstrich gefolgt von doppelten Anführungszeichen endete, nicht richtig an einen Befehl übergeben und konnte dessen erfolgreiche Ausführung verhindern. Beispiel: Das Argument "C:\\Program Files\" hatte für den Befehl zusätzliche doppelte Anführungszeichen. Durch dieses Update wird das alte Verhalten wiederhergestellt, bei dem der umgekehrte Schrägstrich vor dem abschließenden doppelten Anführungszeichen keine Sonderbehandlung erfährt.
Siehe JDK-8282008
Weitere Hinweise: HttpURLConnection-Standard-Keepalive-Timeout konfigurierbar gemacht
Zwei Systemeigenschaften wurden hinzugefügt, die das Keepalive-Verhalten der HttpURLConnection in Fällen steuern, in denen der Server keine Keepalive-Zeit angibt. Es sind zwei Eigenschaften definiert, mit denen die Verbindungen zu Servern und Proxys separat gesteuert werden. Es handelt sich um http.keepAlive.time.server und http.keepAlive.time.proxy. Weitere Informationen über diese finden Sie unter Netzwerkeigenschaften.
Siehe JDK-8278067
Weitere Hinweise:VisualVM-Tool nicht mehr gebündelt
In dieser Version des JDK ist Java VisualVM nicht mehr enthalten. VisualVM ist nun als separater Download von https://visualvm.github.io verfügbar.
Siehe JDK-8294184

JDK auf dem aktuellen Stand halten

Oracle empfiehlt, das JDK mit jedem kritischen Patchupdate zu aktualisieren. Auf der Seite Sicherheitsbaseline können Sie die aktuelle Version für jede Releasefamilie bestimmen.

Kritische Patchupdates, die Sicherheitslücken beheben, werden ein Jahr im Voraus unter "Critical Patch Updates, Security Alerts and Bulletins" bekannt gegeben. Es wird nicht empfohlen, dieses JDK (Version 8u361) nach dem nächsten kritischen Patchupdate zu verwenden. Dieses ist für den 18. April 2023 geplant.

Kunden des Java SE-Abonnements, die JRE-Updates/-Installationen für eine große Anzahl an Desktops verwalten, sollten die Verwendung der Java Advanced Management Console (AMC) in Erwägung ziehen.

Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u361) auf Basis eines alternativen Mechanismus am 18. Mai 2023 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren. Weitere Informationen finden Sie unter Ablaufdatum für 23.1.2 JRE im Deployment-Handbuch für Java Platform, Standard Edition.

Bugfixes

Java 8 Update 351 (8u351)

Releasehauptmerkmale

IANA-Zeitzonendaten der Version 2022b, 2022c.
Weitere Informationen finden Sie unter Versionen von Zeitzonendaten in der JRE-Software.
Andere Hinweise: Upgrade des standardmäßigen PKCS12-MAC-Algorithmus
Der standardmäßige MAC-Algorithmus in einem PKCS12-Keystore wurde aktualisiert. Der neue Algorithmus basiert auf SHA-256 und ist stärker als der alte auf SHA-1 basierende Algorithmus. Detaillierte Informationen dazu finden Sie in den Sicherheitseigenschaften. Diese beginnen mit keystore.pkcs12 in der Datei java.security.
Siehe JDK-8267880
Andere Hinweise: Mit SHA-1 signierte JARs wurden deaktiviert
Mit SHA-1-Algorithmen signierte JARs sind jetzt standardmäßig eingeschränkt und werden so behandelt, als wären sie unsigniert. Dies gilt für Algorithmen für Digests und zum Signieren der JAR-Datei und bei Bedarf zum Erstellen von Zeitstempeln für die JAR-Datei. Außerdem gilt es für die Signatur- und Digest-Algorithmen der Zertifikate in der Zertifikatskette des Code-Signaturgebers und der Timestamp Authority sowie für sämtliche CRLs und OCSP-Antworten, die zur Prüfung verwendet werden, falls diese Zertifikate entzogen wurden. Diese Einschränkungen gelten auch für signierte JCE-Provider.
Siehe JDK-8269039
Andere Hinweise: 3DES und RC4 in Kerberos veraltet
Die Kerberos-Verschlüsselungstypen des3-hmac-sha1 und rc4-hmac sind jetzt veraltet und standardmäßig deaktiviert. Benutzer können in der Konfigurationsdatei krb5.conf die Option allow_weak_crypto = true festlegen, um sie (neben anderen schwachen Verschlüsselungstypen, darunter auch des-cbc-crc und des-cbc-md5) auf eigenes Risiko wieder zu aktivieren. Um eine Untergruppe der schwachen Verschlüsselungstypen zu deaktivieren, können Benutzer in den Einstellungen von default_tkt_enctypes, default_tgs_enctypes oder permitted_enctypes bevorzugte Verschlüsselungstypen ausdrücklich auflisten.
Siehe JDK-8139348

JDK auf dem aktuellen Stand halten

Oracle empfiehlt, das JDK mit jedem kritischen Patchupdate zu aktualisieren. Auf der Seite Sicherheitsbaseline können Sie die aktuelle Version für jede Releasefamilie bestimmen.

Kritische Patchupdates, die Sicherheitslücken beheben, werden ein Jahr im Voraus unter "Critical Patch Updates, Security Alerts and Bulletins" bekannt gegeben. Es wird nicht empfohlen, dieses JDK (Version 8u351) nach dem nächsten kritischen Patchupdate zu verwenden. Dieses ist für den 17. Januar 2023 geplant.

Kunden des Java SE-Abonnements, die JRE-Updates/-Installationen für eine große Anzahl an Desktops verwalten, sollten die Verwendung der Java Advanced Management Console (AMC) in Erwägung ziehen.

Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u351) auf Basis eines alternativen Mechanismus am 17. Februar 2023 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren. Weitere Informationen finden Sie unter Ablaufdatum für 23.1.2 JRE im Deployment-Handbuch für Java Platform, Standard Edition.

Bugfixes

» 8u351-Versionshinweise

Java 8 Update 341 (8u341)

Releasehauptmerkmale

IANA-Zeitzonendaten der Version 2022a.
Weitere Informationen finden Sie unter Versionen von Zeitzonendaten in der JRE-Software.
Neues Feature: HTTPS-Kanalbindung für Java GSS/Kerberos wird unterstützt
TLS-Kanalbindungstoken für Negotiate/Kerberos-Authentifizierung über HTTPS per javax.net.HttpsURLConnection werden jetzt unterstützt.

Kanalbindungstoken sind immer häufiger als erweiterte Form von Sicherheit erforderlich. Sie übermitteln die Einschätzung des Clients zum Binding zwischen Verbindungssicherheit (durch ein TLS-Serverzertifikat dargestellt) und hochrangigeren Authentifizierungsdaten (wie Benutzername und Kennwort) von einem Client zu einem Server. Der Server kann dann feststellen, ob der Client von einem MITM getäuscht wurde und die Session/Verbindung herunterfahren.
Siehe JDK-8279842
Neues Feature: TLSv1.3 wurde standardmäßig auf JDK 8u für Clientrollen aktiviert
Die TLSv1.3-Implementierung ist in JDK 8u ab 8u261 verfügbar. Für Serverrollen ist sie standardmäßig aktiviert, aber für Clientrollen ist sie standardmäßig deaktiviert. Ab diesem Release ist TLSv1.3 jetzt auch standardmäßig für Clientrollen aktiviert. Weitere Einzelheiten finden Sie im Abschnitt Additional Information der Oracle JRE and JDK Cryptographic Roadmap.
Siehe JDK-8245263
Weitere Hinweise:java.net.InetAddress wurde aktualisiert und erkennt nun mehrdeutige IPv4-Adressliterale
Die Klasse java.net.InetAddress wurde aktualisiert, um IPv4-Adressliterale in dezimaler Quad-Notation grundsätzlich zu akzeptieren. Die Methoden der Klasse InetAddress werden aktualisiert, um eine java.net.UnknownHostException für ungültige IPv4-Adressliterale auszulösen. Um diese Prüfung zu deaktivieren, kann die neue Systemeigenschaft "jdk.net.allowAmbiguousIPAddressLiterals" auf "true" eingestellt werden.
Siehe JDK-8277608 (nicht allgemein zugänglich)
Weitere Hinweise: JDK Bundle-Erweiterungen nach Download mit Firefox 102 abgeschnitten
Auf oracle.com und java.com werden bestimmte JDK Bundle-Erweiterungen beim Download mit Firefox Version 102 abgeschnitten. Die heruntergeladenen Bundles haben keine Dateierweiterungen wie ".exe", ".rpm", ".deb". Wenn Sie das Upgrade auf Firefox ESR 102.0.1 oder Firefox 103 nach dessen Release nicht durchführen können, dann können Sie das Problem wie folgt umgehen:
‐ Fügen Sie dem Dateinamen nach dem Download manuell eine Dateierweiterung hinzu.
‐ Verwenden Sie einen anderen Browser
Siehe JDK-8277093

JDK auf dem aktuellen Stand halten

Oracle empfiehlt, das JDK mit jedem kritischen Patchupdate zu aktualisieren. Auf der Seite Sicherheitsbaseline können Sie die aktuelle Version für jede Releasefamilie bestimmen.

Kritische Patchupdates, die Sicherheitslücken beheben, werden ein Jahr im Voraus unter "Critical Patch Updates, Security Alerts and Bulletins" bekannt gegeben. Es wird nicht empfohlen, dieses JDK (Version 8u341) nach dem nächsten kritischen Patchupdate zu verwenden. Dieses ist für den 18. Oktober 2022 geplant.

Kunden des Java SE-Abonnements, die JRE-Updates/-Installationen für eine große Anzahl an Desktops verwalten, sollten die Verwendung der Java Advanced Management Console (AMC) in Erwägung ziehen.

Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u341) auf Basis eines alternativen Mechanismus am 18. November 2022 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren. Weitere Informationen finden Sie unter Ablaufdatum für 23.1.2 JRE im Deployment-Handbuch für Java Platform, Standard Edition.

Bugfixes

» 8u341-Versionshinweise

Java 8 Update 333 (8u333)

Releasehauptmerkmale

IANA-Zeitzonendaten der Version 2021a.
Weitere Informationen finden Sie unter Versionen von Zeitzonendaten in der JRE-Software.
Änderung: Alternative Windows-Datenstreams standardmäßig aktivieren
Die Windows-Implementierung von java.io.File wurde geändert, damit standardmäßig keine strengen Gültigkeitsprüfungen für Dateipfade ausgeführt werden. So sind beispielsweise Doppelpunkte (":") im Pfad an anderen Stellen als unmittelbar nach einem einzelnen Laufwerksbuchstaben zulässig. Außerdem sind damit Pfade erlaubt, die alternative NTFS-Datenstreams (ADS) darstellen, wie "filename:streamname". Damit wird das Standardverhalten von java.io.File auf den Zustand vor dem CPU vom April 2022 zurückgesetzt, bei dem standardmäßig keine strengen Gültigkeitsprüfungen für Dateipfade unter Windows ausgeführt wurden. Wenn Sie strenge Prüfungen von Pfaden in java.io.File wieder aktivieren möchten, setzen Sie die Systemeigenschaft jdk.io.File.enableADS auf false (ohne Beachtung der Groß-/Kleinschreibung). Diese Einstellung kann beispielsweise vorzuziehen sein, wenn keine speziellen Windows-Gerätepfade wie NUL: verwendet werden.
Siehe JDK-8285445

JDK auf dem aktuellen Stand halten

Oracle empfiehlt, das JDK mit jedem kritischen Patchupdate zu aktualisieren. Auf der Seite Sicherheitsbaseline können Sie die aktuelle Version für jede Releasefamilie bestimmen.

Kritische Patchupdates, die Sicherheitslücken beheben, werden ein Jahr im Voraus unter "Critical Patch Updates, Security Alerts and Bulletins" bekannt gegeben. Es wird nicht empfohlen, dieses JDK (Version 8u333) nach dem nächsten kritischen Patchupdate zu verwenden. Dieses ist für den 19. Juli 2022 geplant.

Kunden des Java SE-Abonnements, die JRE-Updates/-Installationen für eine große Anzahl an Desktops verwalten, sollten die Verwendung der Java Advanced Management Console (AMC) in Erwägung ziehen.

Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u333) auf Basis eines alternativen Mechanismus am 19. August 2022 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren. Weitere Informationen finden Sie unter Ablaufdatum für 23.1.2 JRE im Deployment-Handbuch für Java Platform, Standard Edition.

Bugfixes

Dieses Release basiert auf dem vorherigen CPU und umfasst keine zusätzlichen Sicherheits-Fixes. Eine Liste der in diesem Release enthaltenen Bugfixes finden Sie auf der Seite JDK 8u223-Versionshinweise.

» 8u333-Versionshinweise

Java 8 Update 331 (8u331)

Releasehauptmerkmale

IANA-Zeitzonendaten der Version 2021e.
Weitere Informationen finden Sie unter Versionen von Zeitzonendaten in der JRE-Software.
Neues Feature: Neue Grenzwerte für die XML-Verarbeitung
Drei Verarbeitungsgrenzwerte wurden hinzugefügt. Im Einzelnen:
- jdk.xml.xpathExprGrpLimit
  Beschreibung: Begrenzt die Anzahl der Gruppen, die in einem XPath-Ausdruck enthalten sein können.
  Typ: Ganzzahl
  Wert: Eine positive Ganzzahl. Mit einem Wert, der kleiner/gleich Null ist, wird kein Grenzwert angegeben. Wenn der Wert keine Ganzzahl ist, wird eine NumberFormatException ausgelöst. Standardwert: 10.
- jdk.xml.xpathExprOpLimit
  Beschreibung: Begrenzt die Anzahl der Operatoren, die in einem XPath enthalten sein können.
  Typ: Ganzzahl
  Wert: Eine positive Ganzzahl. Mit einem Wert, der kleiner/gleich Null ist, wird kein Grenzwert angegeben. Wenn der Wert keine Ganzzahl ist, wird eine NumberFormatException ausgelöst. Standardwert: 100.
- jdk.xml.xpathTotalOpLimit
  Beschreibung: Begrenzt die Gesamtzahl der XPath-Operatoren in einem XSL-Stylesheet.
  Typ: Ganzzahl
  Wert: Eine positive Ganzzahl. Mit einem Wert, der kleiner/gleich Null ist, wird kein Grenzwert angegeben. Wenn der Wert keine Ganzzahl ist, wird eine NumberFormatException ausgelöst. Standardwert: 10000.
Unterstützte Prozessoren
- jdk.xml.xpathExprGrpLimit und jdk.xml.xpathExprOpLimit werden vom XPath-Prozessor unterstützt.
- Alle drei Grenzwerte werden vom XSLT-Prozessor unterstützt.
Eigenschaften festlegen
Die Eigenschaften für den XSLT-Prozessor können über die TransformerFactory geändert werden. Beispiel:
```
<code>        TransformerFactory factory = TransformerFactory.newInstance();

        factory.setAttribute("jdk.xml.xpathTotalOpLimit", "1000");
```
Die Eigenschaften für XPath- und XSLT-Prozessor können über die Systemeigenschaft und die Konfigurationsdatei jaxp.properties im Verzeichnis conf der Java-Installation festgelegt werden. Beispiel:
```
<code>        System.setProperty("jdk.xml.xpathExprGrpLimit", "20");
```
oder in der Datei jaxp.properties:
```
<code>        jdk.xml.xpathExprGrpLimit=20
```
JDK-8270504 (nicht allgemein zugänglich)
Weitere Hinweise: Nur Zertifikate mit korrekten Trust-Einstellungen werden als Einträge vertrauenswürdiger Zertifikate im macOS-KeychainStore zugänglich gemacht
Unter macOS werden nur Zertifikate mit korrekten Trust-Einstellungen im Benutzerschlüsselbund als Einträge vertrauenswürdiger Zertifikate im KeychainStore-Keystore zugänglich gemacht. Außerdem führt der Aufruf der Methode KeyStore::setCertificateEntry oder des Befehls keytool -importcert für einen KeychainStore-Keystore jetzt zu einer KeyStoreException. Rufen Sie stattdessen den macOS-Befehl "security add-trusted-cert" auf, um ein vertrauenswürdiges Zertifikat im Benutzerschlüsselbund hinzuzufügen.
JDK-8278449 (nicht allgemein zugänglich)
Weitere Hinweise: Das Parsing von URLs in den integrierten LDAP-, DNS-, RMI- und CORBA-JNDI-Providern wurde strenger gestaltet. Die Parsingstärke kann mit Systemeigenschaften gesteuert werden:
Das Parsing von URLs in den integrierten LDAP-, DNS- und RMI-JNDI-Providern wurde strenger gestaltet. Die Parsingstärke kann mit Systemeigenschaften gesteuert werden:
```
<code>  -Dcom.sun.jndi.ldapURLParsing="legacy" | "compat" | "strict" (to control "ldap:" URLs)


  -Dcom.sun.jndi.dnsURLParsing="legacy" | "compat" | "strict" (to control "dns:" URLs)

  -Dcom.sun.jndi.rmiURLParsing="legacy" | "compat" | "strict" (to control "rmi:" URLs)

  -Dcom.sun.jndi.corbaURLParsing="legacy" | "compat" | "strict" (to control "iiop:" and "iiopname:" URLs)
```
Der Standardwert lautet für alle Eigenschaften "compat".
- Mit dem Modus "legacy" können Sie die neue Validierung ausschalten.
- Über den Modus "compat" begrenzen Sie Inkompatibilitäten.
- Der Modus "strict" ist strenger und kann zu Regression führen, wenn URLs abgelehnt werden, die eine Anwendung als gültig betrachtet.
Wenn eine unzulässige URL-Zeichenfolge ermittelt wird, wird eine javax.naming.NamingException (oder eine entsprechende Unterklasse) ausgelöst.
JDK-8278972 (nicht allgemein zugänglich)

JDK auf dem aktuellen Stand halten

Oracle empfiehlt, das JDK mit jedem kritischen Patchupdate zu aktualisieren. Auf der Seite Sicherheitsbaseline können Sie die aktuelle Version für jede Releasefamilie bestimmen.

Kritische Patchupdates, die Sicherheitslücken beheben, werden ein Jahr im Voraus unter "Critical Patch Updates, Security Alerts and Bulletins" bekannt gegeben. Es wird nicht empfohlen, dieses JDK (Version 8u331) nach dem nächsten kritischen Patchupdate zu verwenden. Dieses ist für den 19. Juli 2022 geplant.

Kunden des Java SE-Abonnements, die JRE-Updates/-Installationen für eine große Anzahl an Desktops verwalten, sollten die Verwendung der Java Advanced Management Console (AMC) in Erwägung ziehen.

Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u331) auf Basis eines alternativen Mechanismus am 19. August 2022 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren. Weitere Informationen finden Sie unter Ablaufdatum für 23.1.2 JRE im Deployment-Handbuch für Java Platform, Standard Edition.

Bugfixes

» 8u331-Versionshinweise

Java 8 Update 321 (8u321)

Releasehauptmerkmale

IANA-Zeitzonendaten der Versionen 2021b, 2021c, 2021d, 2021e.
JDK 8u321 enthält IANA-Zeitzonendaten der Versionen 2021b, 2021c, 2021d, 2021e. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.
Neues Feature: Neue Konfigurationseigenschaften für SunPKCS11
SunPKCS11-Provider fügt neue Providerkonfigurationsattribute hinzu, um die native Ressourcennutzung besser zu steuern. Der SunPKCS11-Provider beansprucht native Ressourcen für native PKCS11-Librarys. Um die nativen Ressourcen verwalten und besser steuern zu können, werden zusätzliche Konfigurationsattribute hinzugefügt. Diese steuern die Häufigkeit, mit der native Referenzen gelöscht werden, und ob das zugrundeliegende PKCS11-Token nach dem Abmelden endgültig gelöscht werden soll.
Siehe JDK-8240256
Entfernte Features und Optionen: GlobalSign Root-Zertifikat von Google wurde entfernt
Das folgende Root-Zertifikat von Google wurde aus dem cacerts-Keystore entfernt:
+ alias name "globalsignr2ca [jdk]" Distinguished Name: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2
Siehe JDK-8225083
Weitere Hinweise: Zeitzonendaten wurden auf die Version 2021c aktualisiert
In der IANA-Zeitzonendatenbank, auf der die JDK-Libraries für Datum/Uhrzeit basieren, wurden einige Zeitzonenregeln auf seit Version 2021c geltende Regeln angepasst. Beachten Sie, dass seit diesem Update einige der Zeitzonenregeln vor dem Jahr 1970 gemäß den mit Version 2021b eingeführten Änderungen geändert wurden. Weitere Informationen finden Sie in der Ankündigung für Version 2021b
Siehe JDK-8274407

JDK auf dem aktuellen Stand halten

Oracle empfiehlt, das JDK mit jedem kritischen Patchupdate (Critical Patch Update, CPU) zu aktualisieren. Auf der Seite "Sicherheitsbaseline" können Sie die aktuelle Version für jede Releasefamilie bestimmen.

Kritische Patchupdates, die Sicherheitslücken beheben, werden ein Jahr im Voraus unter Critical Patch Updates, Security Alerts and Bulletins bekannt gegeben. Es wird nicht empfohlen, dieses JDK (Version 8u291) nach dem nächsten kritischen Patchupdate zu verwenden. Dieses ist für den 20. Juli 2021 geplant.

Kunden des Java SE-Abonnements, die JRE-Updates/-Installationen für eine große Anzahl an Desktops verwalten, sollten die Verwendung der Java Advanced Management Console (AMC) in Erwägung ziehen.

Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u291) auf Basis eines alternativen Mechanismus am 20. August 2021 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren. Weitere Informationen finden Sie unter Ablaufdatum für 23.1.2 JRE im Deployment-Handbuch für Java Platform, Standard Edition.

Bugfixes

» 8u321-Versionshinweise

Java 8 Update 311 (8u311)

Releasehauptmerkmale

IANA-Zeitzonendaten der Version 2021a.
Weitere Informationen finden Sie unter Versionen von Zeitzonendaten in der JRE-Software.
Neues Feature: Marlin-Renderer in JDK 8u
Ab Version 8u311 werden der Marlin-Grafik-Rasterizer und seine Artefakte in den JDK-/JRE-Bundles erstellt und verteilt. Dabei handelt es sich nicht um die Standardrendering-Engine. Sie können die Engine aber durch Festlegen der folgenden Systemeigenschaft aktivieren:
sun.java2d.renderer=sun.java2d.marlin.MarlinRenderingEngine
Siehe JDK-8143849
Neues Feature: Untergruppe von kontextspezifischem Deserialisierungsfilter
Anwendungen können kontextspezifische und dynamisch ausgewählte Deserialisierungsfilter über eine JVM-weite Filter-Factory konfigurieren, die zum Auswählen eines Filters für jeden Deserialisierungsstream aufgerufen wird. Das Verhalten ist eine strikte Untergruppe von JEP 415: Kontextspezifischer Deserialisierungsfilter. Damit können Sie eine Filter-Factory mit einer Eigenschaft in der Befehlszeile oder in der Sicherheitseigenschaftendatei konfigurieren.
Details dazu finden Sie unter Kontextspezifischer Deserialisierungsfilter und in der Dokumentation zur Serialisierungsfilterung.
JDK-8268680 (nicht allgemein zugänglich)
Entfernte Features und Optionen: IdenTrust-Root-Zertifikat wurde entfernt
Das folgende Root-Zertifikat von IdenTrust wurde aus dem cacerts-Keystore entfernt:
+ alias name "identrustdstx3 [jdk]"
Distinguished Name: CN=DST Root CA X3, O=Digital Signature Trust Co.
Siehe JDK-8225082
Weitere Hinweise: Release erkennt Windows 11 nicht korrekt
Dieses Release kann Windows 11 nicht korrekt identifizieren. Die Eigenschaft os.name ist bei Windows 11 auf Windows 10 gesetzt. In HotSpot-Fehlerlogs wird das BS als Windows 10 angegeben. Das HotSpot-Fehlerlog zeigt aber die Build-Nummer an. Windows 11 hat Build 22000.194 oder höher.
Siehe JDK-8274840
Weitere Hinweise: Die Voreinstellung für standardmäßig aktivierte Cipher Suite wurde aktualisiert
Die Standardprioritätsfolge der Cipher Suite für TLS 1.0 bis TLS 1.3 wurde angepasst.
Bei TLS 1.3 wird jetzt TLS_AES_256_GCM_SHA384 der Suite TLS_AES_128_GCM_SHA256 vorgezogen.
Bei TLS 1.0 bis TLS 1.2 haben einige der Zwischensuites wie folgt eine niedrigere Priorität erhalten:
- Cipher Suites, die Forward Secrecy nicht beibehalten, haben jetzt eine niedrigere Priorität als Suites, die Forward Secrecy unterstützen.
- Cipher Suites mit SHA-1 haben eine niedrigere Priorität erhalten.
Siehe JDK-8163326
Weitere Hinweise: Änderung des HttpURLConnection-Verhaltens, wenn kein geeigneter Proxy gefunden wird
Das Verhalten von HttpURLConnection bei der Verwendung von ProxySelector wurde in diesem JDK-Release geändert. HttpURLConnection unternahm zuvor einen direkten Verbindungsversuch, wenn die konfigurierten Proxys keine Verbindung herstellen konnten. Ab diesem Release wurde das Standardverhalten geändert. Es wird jetzt keine direkte Verbindung mehr verwendet, wenn der erste Proxyverbindungsversuch nicht erfolgreich ist.
Siehe JDK-8161016

JDK auf dem aktuellen Stand halten

Oracle empfiehlt, das JDK mit jedem kritischen Patchupdate zu aktualisieren. Auf der Seite Sicherheitsbaseline können Sie die aktuelle Version für jede Releasefamilie bestimmen.

Kritische Patchupdates, die Sicherheitslücken beheben, werden ein Jahr im Voraus unter "Critical Patch Updates, Security Alerts and Bulletins" bekannt gegeben. Es wird nicht empfohlen, dieses JDK (Version 8u311) nach dem nächsten kritischen Patchupdate zu verwenden. Dieses ist für den 18. Januar 2022 geplant.

Kunden des Java SE-Abonnements, die JRE-Updates/-Installationen für eine große Anzahl an Desktops verwalten, sollten die Verwendung der Java Advanced Management Console (AMC) in Erwägung ziehen.

Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u311) auf Basis eines alternativen Mechanismus am 18. Februar 2022 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren. Weitere Informationen finden Sie unter Ablaufdatum für 23.1.2 JRE im Deployment-Handbuch für Java Platform, Standard Edition.

Bugfixes

» 8u311-Versionshinweise

Java 8 Update 301 (8u301)

Releasehauptmerkmale

IANA-Zeitzonendaten der Version 2021a.
JDK 8u301 enthält Version 2021a der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.
Neues Feature: Anpassung der PKCS12-Keystore-Generierung
Neue System- und Sicherheitseigenschaften wurden hinzugefügt, damit Benutzer die Generierung von PKCS12-Keystores anpassen können. Diese umfassen Algorithmen und Parameter für Schlüsselschutz, Zertifikatsschutz und MacData. Die detaillierte Erläuterung und die möglichen Werte für diese Eigenschaften finden Sie im Abschnitt "PKCS12 KeyStore properties" der Datei java.security.
Siehe JDK-8076190
Entfernte Features und Optionen: Root-Zertifikate mit 1024-Bit-Schlüsseln wurden entfernt
Root-Zertifikate mit schwachen 1024-Bit-RSA-Public Keys wurden aus dem cacerts-Keystore entfernt.
Siehe JDK-8243559
Entfernte Features und Optionen: Sonera Class2 CA-Zertifikat von Telia Company wurde entfernt
Das folgende Root-Zertifikat wurde aus dem cacerts-Truststore entfernt:
+ Telia Company + soneraclass2ca DN: CN=Sonera Class2 CA, O=Sonera, C=FI
Siehe JDK-8225081
Weitere Hinweise: Für die standardmäßigen PKCS12-Verschlüsselungsalgorithmen wurde ein Upgrade durchgeführt
Die standardmäßigen Verschlüsselungsalgorithmen in einem PKCS12-Keystore wurden aktualisiert. Die neuen Algorithmen basieren auf AES-256 und SHA-256. Sie sind stärker als die alten Algorithmen, die auf RC2, DESede und SHA-1 basierten. Detaillierte Informationen dazu finden Sie in den Sicherheitseigenschaften. Diese beginnen mit keystore.pkcs12 in der Datei java.security.
Zur Kompatibilität wird die neue Systemeigenschaft keystore.pkcs12.legacy definiert, die die Algorithmen auf die älteren, schwächeren Versionen zurücksetzt. Für diese Eigenschaft ist kein Wert definiert.
Siehe JDK-8153005

JDK auf dem aktuellen Stand halten

Oracle empfiehlt, das JDK mit jedem kritischen Patchupdate zu aktualisieren. Auf der Seite Sicherheitsbaseline können Sie die aktuelle Version für jede Releasefamilie bestimmen.

Kritische Patchupdates, die Sicherheitslücken beheben, werden ein Jahr im Voraus unter Critical Patch Updates, Security Alerts and Bulletins bekannt gegeben. Es wird nicht empfohlen, dieses JDK (Version 8u301) nach dem nächsten kritischen Patchupdate zu verwenden. Dieses ist für den 19. Oktober 2021 geplant.

Kunden des Java SE-Abonnements, die JRE-Updates/-Installationen für eine große Anzahl an Desktops verwalten, sollten die Java Advanced Management Console (AMC) verwenden.

Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u301) auf Basis eines alternativen Mechanismus am 19. November 2021 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren. Weitere Informationen finden Sie unter Ablaufdatum für 23.1.2 JRE im Deployment-Handbuch für Java Platform, Standard Edition.

Bugfixes

» 8u301-Versionshinweise

Java 8 Update 291 (8u291)

Releasehauptmerkmale

IANA-Zeitzonendaten der Versionen 2020e, 2020f, 2021a.
JDK 8u291 enthält IANA-Zeitzonendaten der Versionen 2020e, 2020f, 2021a. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.
Weitere Hinweise: Neue System- und Sicherheitseigenschaften zur Steuerung der Neuerstellung von Remoteobjekten durch die integrierten JNDI-RMI- und -LDAP-Implementierungen des JDK
jdk.jndi.object.factoriesFilter: Mit dieser System- und Sicherheitseigenschaft kann ein serieller Filter zur Steuerung des Sets von Objekt-Factory-Klassen angegeben werden, die Objekte aus Objektreferenzen instanziieren dürfen, die von Naming-/Directory-Systemen zurückgegeben werden. Die von der Referenzinstanz benannte Factory-Klasse wird bei der Neuerstellung der Remotereferenz mit diesem Filter abgeglichen. Die Filtereigenschaft unterstützt die musterbasierte Filtersyntax mit dem von JEP 290 angegebenen Format. Diese Eigenschaft gilt für die integrierten Providerimplementierungen von JNDI/RMI und JNDI/LDAP gleichermaßen. Der Standardwert ermöglicht einer beliebigen in der Referenz angegebenen Objekt-Factory-Klasse das Neuerstellen des referenzierten Objekts.
JDK-8244473 (nicht allgemein zugänglich)
Weitere Hinweise: Die Java-Standardversion wird nicht für eine JAR-Ausführung per Doppelklick aktualisiert
Wenn die PATH-Umgebungsvariable einen Datensatz enthält, der von Oracle JDK-Installationsprogrammen aus neueren Releases konfiguriert wurde, fügt das Oracle JRE-Installationsprogramm den Pfad zu dem Verzeichnis, das die Java-Befehle (java.exe, javaw.exe und javaws.exe) enthält, in der PATH-Umgebungsvariablen nach diesem Datensatz ein. Zuvor ignorierte das Oracle JRE-Installationsprogramm Änderungen, die von Oracle JDK-Installationsprogrammen aus neueren Releases an der PATH-Umgebungsvariablen vorgenommen wurden, und aktualisierte den Wert der PATH-Umgebungsvariablen nicht korrekt. Weitere technische Informationen finden Sie im folgenden CSR: https://bugs.openjdk.java.net/browse/JDK-8259858
Siehe JDK-8259215
Weitere Hinweise: TLS 1.0 und 1.1 deaktiviert
TLS 1.0 und 1.1 sind Versionen des TLS-Protokolls, die nicht mehr als sicher erachtet werden und durch sicherere und modernere Versionen (TLS 1.2 und 1.3) ersetzt wurden.
Diese Versionen wurden jetzt standardmäßig deaktiviert. Wenn Probleme auftreten, können Sie auf eigenes Risiko die Versionen erneut aktivieren, indem Sie "TLSv1" und/oder "TLSv1.1" in der Konfigurationsdatei java.security aus der Sicherheitseigenschaft jdk.tls.disabledAlgorithms entfernen.
Siehe JDK-8202343
Weitere Hinweise: TLS 1.0 und 1.1 für Java-Plug-in-Applets und Java Web Start-Anwendungen deaktivieren
TLS 1.0 und 1.1 wurden deaktiviert. Diese Protokolle werden von Java-Plug-in-Applets und Java Web Start-Anwendungen nicht standardmäßig verwendet. Wenn Probleme auftreten, ist eine Option zur erneuten Aktivierung der Protokolle über das Java Control Panel verfügbar.
JDK-8255892 (nicht allgemein zugänglich)

JDK auf dem aktuellen Stand halten

Kritische Patchupdates, die Sicherheitslücken beheben, werden ein Jahr im Voraus unter Critical Patch Updates, Security Alerts and Bulletins bekannt gegeben. Es wird nicht empfohlen, dieses JDK (Version 8u291) nach dem nächsten kritischen Patchupdate zu verwenden. Dieses ist für den 20. Juli 2021 geplant.

Kunden des Java SE-Abonnements, die JRE-Updates/-Installationen für eine große Anzahl an Desktops verwalten, sollten die Verwendung der Java Advanced Management Console (AMC) in Erwägung ziehen.

Bugfixes

» 8u291-Versionshinweise

Java 8 Update 281 (8u281)

Releasehauptmerkmale

IANA Data 2020d
JDK 8u281 enthält Version 2020d der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.
Neues Feature: "groupname"-Option zum Schlüsselpaargenerierungs-Keytool hinzugefügt
Eine neue -groupname-Option wurde zu keytool -genkeypair hinzugefügt, sodass Benutzer beim Generieren eines Schlüsselpaares eine benannte Gruppe angeben können. Beispiel: keytool -genkeypair -keyalg EC -groupname secp384r1 generiert ein EC-Schlüsselpaar unter Verwendung der secp384r1-Kurve. Da mehrere Kurven mit derselben Größe vorhanden sein können, wird die Verwendung der Option -groupname gegenüber der Option -keysize bevorzugt.
Siehe JDK-8213400
Neues Feature: Apache Santuario Library-Update auf Version 2.1.4
Die Apache Santuario Library wurde auf Version 2.1.4 aktualisiert. Dementsprechend wurde die neue Systemeigenschaft com.sun.org.apache.xml.internal.security.parser.pool-size eingeführt.
Diese neue Systemeigenschaft legt die Poolgröße des internen DocumentBuilder-Cache fest, der beim Verarbeiten der XML-Signaturen verwendet wird. Die Funktion entspricht der in Apache Santuario verwendeten Systemeigenschaft org.apache.xml.security.parser.pool-size und hat denselben Standardwert (20).
Siehe JDK-8231507
Neues Feature: Unterstützung für certificate_authorities-Erweiterung
Die Erweiterung "certificate_authorities" ist eine in TLS 1.3 eingeführte optionale Erweiterung. Damit werden die Certificate Authoritys (CAs) angegeben, die ein Endpunkt unterstützt. Der empfangende Endpunkt muss diese bei der Auswahl des Zertifikats berücksichtigen.
Siehe JDK-8206925
Weitere Hinweise: Properties.loadFromXML zwecks Übereinstimmung mit Spezifikation geändert
Die Implementierung der java.util.Properties loadFromXML-Methode wurde geändert, um mit ihrer Spezifikation konform zu sein. Insbesondere lehnt die zugrunde liegende XML-Parserimplementierung jetzt nicht konforme XML-Dokumente durch Ausgabe einer InvalidPropertiesFormatException-Ausnahme ab, wie in der loadFromXML-Methode angegeben.
Siehe JDK-8213325
Weitere Hinweise: US/Pacific-New-Zonenname im Rahmen von tzdata2020b entfernt
Im Rahmen des JDK-Updates auf tzdata2020b wurden die längst veralteten Dateien namens pacificnew und systemv entfernt. Daher kann die in der pacificnew-Datendatei deklarierte Zone namens "US/Pacific-New" nicht mehr verwendet werden.
Siehe JDK-8254177

JDK auf dem aktuellen Stand halten

Kritische Patchupdates, die Sicherheitslücken beheben, werden ein Jahr im Voraus unter Critical Patch Updates, Security Alerts and Bulletins bekannt gegeben. Es wird nicht empfohlen, dieses JDK (Version 8u281) nach dem nächsten kritischen Patchupdate zu verwenden. Dieses ist für den 20. April 2021 geplant.

Kunden des Java SE-Abonnements, die JRE-Updates/-Installationen für eine große Anzahl an Desktops verwalten, sollten die Verwendung der Java Advanced Management Console (AMC) in Erwägung ziehen.

Bei Systemen, die nicht auf Oracle Server zugreifen können, läuft diese JRE (Version 8u281) auf Basis eines alternativen Verfahrens am 15. Mai 2021 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren. Weitere Informationen finden Sie unter Ablaufdatum für 23.1.2 JRE im Deployment-Handbuch für Java Platform, Standard Edition.

Bugfixes

» 8u281-Versionshinweise

Java 8 Update 271 (8u271)

Releasehauptmerkmale

IANA Data 2020a
JDK 8u271 enthält Version 2020a der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.
Neues Feature: Kurven mit schwachen Namen standardmäßig deaktiviert in TLS, CertPath und signierter JAR
Kurven mit schwachen Namen werden standardmäßig deaktiviert, indem sie den folgenden disabledAlgorithms-Sicherheitseigenschaften hinzugefügt werden: jdk.tls.disabledAlgorithms, jdk.certpath.disabledAlgorithms und jdk.jar.disabledAlgorithms. Da 47 Kurven mit schwachen Namen deaktiviert werden müssen, wäre es zu aufwendig, einzelne benannte Kurven zu jeder disabledAlgorithms-Eigenschaft hinzuzufügen. Daher wurde die neue Sicherheitseigenschaft jdk.disabled.namedCurves implementiert, in der die benannten Kurven aufgelistet werden können, die allen disabledAlgorithms-Eigenschafen gemeinsam sind. Um die neue Eigenschaft in den disabledAlgorithms-Eigenschaften zu verwenden, stellen Sie das Schlüsselwort include dem vollständigen Eigenschaftsnamen voran. Benutzer können weiterhin einzelne benannte Kurven unabhängig von dieser neuen Eigenschaft zu disabledAlgorithms-Eigenschaften hinzufügen. Es können keine anderen Eigenschaften in die disabledAlgorithms-Eigenschaften aufgenommen werden.
Siehe JDK-8233228
Neues Feature: Unterstützung für Realm-übergreifende Kerberos-Referrals (RFC 6806)
Der Kerberos-Client wurde durch Unterstützung für Kanonisierung des Principal-Namens und Realm-übergreifende Referrals gemäß der RFC 6806-Protokollerweiterung ergänzt.
Mit diesem neuen Feature kann der Kerberos-Client dynamischere Umgebungskonfigurationen nutzen und muss dabei nicht unbedingt (im Voraus) wissen, wie die Realm eines Ziel-Principals (Benutzer oder Service) zu erreichen ist.
Siehe JDK-8223172
Entferntes Feature: Java-Plug-in wird für Linux-, Solaris- und MacOS-Plattformen von JDK 8u entfernt
NPAPI gilt als anfälliges Plug-in, das in vielen Browsern deaktiviert wurde. Das Java-Plug-in, das auf NPAPI basiert, wird derzeit von keinen Browsern auf Linux-, Solaris- und MacOS-Plattformen unterstützt.
Ab 8u271 werden der Teil des Java-Plug-ins, der für Integration und Interaktion mit einem Browser (insbesondere libnpjp2-Library) verantwortlich ist, und ein zugehöriges Artefakt nicht mehr erstellt. Sie sind dann nicht mehr Teil der JRE-Distribution auf Linux-, Solaris- und MacOS-Plattformen.
JDK-8240210 (nicht allgemein zugänglich)
Weitere Hinweise: Eigenschaft wurde hinzugefügt, um zu steuern, welche LDAP-Authentifizierungsmechanismen für die Authentifizierung über "Clear"-Verbindungen zulässig sind
Die neue Umgebungseigenschaft jdk.jndi.ldap.mechsAllowedToSendCredentials wurde hinzugefügt, um zu steuern, welche LDAP-Authentifizierungsmechanismen für das Senden von Zugangsdaten über clear-LDAP-Verbindungen zulässig sind (also nicht mit TLS gesicherte Verbindungen). Eine verschlüsselte LDAP-Verbindung ist eine Verbindung, die mit dem ldaps-Schema geöffnet oder mit dem ldap-Schema geöffnet und dann mit einem STARTTLS-Erweiterungsvorgang auf TLS upgegradet wird.
JDK-8237990 (nicht allgemein zugänglich)

JDK auf dem aktuellen Stand halten

Oracle empfiehlt, das JDK mit jedem kritischen Patchupdate (Critical Patch Update, CPU) zu aktualisieren. Auf der folgenden Seite "Sicherheitsbaseline" können Sie die aktuelle Version für jede Releasefamilie bestimmen.

Kritische Patchupdates, die Sicherheitslücken beheben, werden ein Jahr im Voraus unter Critical Patch Updates, Security Alerts and Bulletins bekannt gegeben. Es wird nicht empfohlen, dieses JDK (Version 8u271) nach dem nächsten kritischen Patchupdate zu verwenden. Dieses ist für den 19. Januar 2021 geplant.

Kunden des Java SE-Abonnements, die JRE-Updates/-Installationen für eine große Anzahl an Desktops verwalten, sollten die Verwendung der Java Advanced Management Console (AMC) in Erwägung ziehen.

Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u271) auf Basis eines alternativen Mechanismus am 20. Februar 2021 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren. Weitere Informationen finden Sie unter Ablaufdatum für 23.1.2 JRE im Deployment-Handbuch für Java Platform, Standard Edition.

Bugfixes

» 8u271-Versionshinweise

Java 8 Update 261 (8u261)

Releasehauptmerkmale

IANA Data 2020a
JDK 8u261 enthält Version 2020a der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.
Neues Feature: Abhängigkeitsänderungen von Windows Visual Studio Library (DLL) und JDK/JRE zur Laufzeit
Im Rahmen der fortwährenden Wartung wird die Microsoft Visual Studio 2017-Toolkette zur Entwicklung von JDK 7 und JDK 8 für Windows verwendet. JDK 8u261 wurde in dem CPU vom Juli 2020 mit Visual Studio 2017 entwickelt. Mit der Veröffentlichung des CPU im Oktober 2020 wechselt JDK 7u281 zu Visual Studio 2017.
JDK-8246783 (nicht allgemein zugänglich)
Neues Feature: JEP 332 Transport Layer Security (TLS) 1.3
JDK 8u261 umfasst eine Implementierung der TLS-(Transport Layer Security-)1.3-Spezifikation (RFC 8446). Weitere Details, einschließlich einer Liste der unterstützten Features, finden Sie im Referenzhandbuch zu Java Secure Socket Extension (JSSE) und in JEP 332.
Siehe JDK-814252
Neues Feature: Neue Systemeigenschaften zur Konfiguration der TLS-Signaturschemas
Zur Anpassung der TLS-Signaturschemas in JDK wurden zwei neue Systemeigenschaften hinzugefügt.
jdk.tls.client.SignatureSchemes wurde für die TLS-Clientseite und jdk.tls.server.SignatureSchemes für die Serverseite hinzugefügt.
Siehe JDK-8242141
Neues Feature: Negotiated Finite Field Diffie-Hellman Ephemeral-Parameter für TLS
Die JDK SunJSSE-Implementierung unterstützt jetzt den in RFC 7919 definierten TLS FFDHE-Mechanismus. Wenn ein Server die TLS-Erweiterung supported_groups oder die benannten Gruppen in der Erweiterung nicht verarbeiten kann, können Anwendungen entweder die unterstützten Gruppennamen mit jdk.tls.namedGroups anpassen oder die FFDHE-Mechanismen deaktivieren, indem sie die Systemeigenschaft jsse.enableFFDHE auf "false" setzen.
Siehe JDK-8140436

JDK auf dem aktuellen Stand halten

Kritische Patchupdates, die Sicherheitslücken beheben, werden ein Jahr im Voraus unter Critical Patch Updates, Security Alerts and Bulletins bekannt gegeben. Es wird nicht empfohlen, dieses JDK (Version 8u261) nach dem nächsten kritischen Patchupdate zu verwenden. Dieses ist für den 13. Oktober 2020 geplant.

Kunden des Java SE-Abonnements, die JRE-Updates/-Installationen für eine große Anzahl an Desktops verwalten, sollten die Verwendung der Java Advanced Management Console (AMC) in Erwägung ziehen.

Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u261) auf Basis eines alternativen Mechanismus am 13. November 2020 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren. Weitere Informationen finden Sie unter Ablaufdatum für 23.1.2 JRE im Deployment-Handbuch für Java Platform, Standard Edition.

Bugfixes

» 8u261-Versionshinweise

Java 8 Update 251 (8u251)

Releasehauptmerkmale

IANA Data 2019c
JDK 8u251 enthält Version 2019c der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.
Neues Feature: PKCS#1 v2.2-Algorithmen, einschließlich RSASSA-PSS-Signatur, werden jetzt unterstützt
Die Provider SunRsaSign und SunJCE unterstützen jetzt weitere Algorithmen, die in PKCS#1 v2.2 definiert sind, darunter RSASSA-PSS-Signatur und OAEP mit FIPS 180-4-Digestalgorithmen. Neue Konstruktoren und Methoden wurden den relevanten JCA/JCE-Klassen unter den Packages java.security.spec und javax.crypto.spec hinzugefügt, um zusätzliche RSASSA-PSS-Parameter zu unterstützen.
Siehe JDK-8146293
Weitere Hinweise: WebEngine begrenzt JavaScript-Methodenaufrufe für bestimmte Klassen
JavaScript-Programme, die im Kontext einer mit WebEngine geladenen Webseite ausgeführt werden, können mit Java-Objekten kommunizieren, die von der Anwendung an das JavaScript-Programm übergeben wurden. JavaScript-Programme, die java.lang.Class-Objekte referenzieren, sind jetzt auf die folgenden Methoden begrenzt:
getCanonicalName getEnumConstants getFields getMethods getName getPackageName getSimpleName getSuperclass getTypeName getTypeParameters isAssignableFrom isArray isEnum isInstance isInterface isLocalClass isMemberClass isPrimitive isSynthetic toGenericString toString

Auf den folgenden Klassen können keine Methoden aufgerufen werden:
java.lang.ClassLoader java.lang.Module java.lang.Runtime java.lang.System java.lang.invoke.* java.lang.module.* java.lang.reflect.* java.security.* sun.misc.*

JDK-8236798 (nicht allgemein zugänglich)
Weitere Hinweise: Neue Oracle-spezifische JDK 8-Updatesystemeigenschaft für Fallback auf Legacy-Base64-Codierungsformat
In Oracle JDK 8u231 wurde ein Upgrade der Apache Santuario-Librarys auf v2.1.3 vorgenommen. Dieses Upgrade hat zu einem Problem geführt, bei dem die XML-Signatur mit Base64-Codierung dazu führte, dass &#xd oder &#13 an die codierte Ausgabe angehängt wurde. Diese Verhaltensänderung wurde in der Apache Santuario-Codebase vorgenommen, um RFC 2045 einzuhalten. Das Santuario-Team hat seine Librarys mit RFC 2045 konform gehalten.
Siehe JDK-8236645

JDK auf dem aktuellen Stand halten

Kritische Patchupdates, die Sicherheitslücken beheben, werden ein Jahr im Voraus unter Critical Patch Updates, Security Alerts and Bulletins bekannt gegeben. Es wird nicht empfohlen, dieses JDK (Version 8u251) nach dem nächsten kritischen Patchupdate zu verwenden. Dieses ist für den 14. Juli 2020 geplant.

Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u251) auf Basis eines alternativen Mechanismus am 14. August 2020 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren. Weitere Informationen finden Sie unter Ablaufdatum für 23.1.2 JRE im Deployment-Handbuch für Java Platform, Standard Edition.

Bugfixes

» 8u251-Versionshinweise

Java 8 Update 241 (8u241)

Releasehauptmerkmale

IANA Data 2019c
JDK 8u241 enthält Version 2019c der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.
Neues Feature: Einschränkung von SASL-Mechanismen zulassen
Die Sicherheitseigenschaft jdk.sasl.disabledMechanisms, mit der Sie SASL-Mechanismen deaktivieren können, wurde hinzugefügt. Jeder deaktivierte Mechanismus wird ignoriert, wenn er im Argument mechanisms von Sasl.createSaslClient oder dem Argument mechanism von Sasl.createSaslServer angegeben ist. Diese Sicherheitseigenschaft ist standardmäßig leer. Das bedeutet, dass keine Mechanismen out-of-the-box deaktiviert sind.
Siehe JDK-8200400
Neues Feature: Upgrade von SunPKCS11-Provider mit Unterstützung für PKCS#11 v2.40
Der SunPKCS11-Provider wurde aktualisiert und unterstützt nun PKCS#11 v2.40. Diese Version unterstützt mehr Algorithmen, wie die AES/GCM/NoPadding-Cipher, DSA-Signaturen mit SHA-2-Nachrichtendigests und RSASSA-PSS-Signaturen, wenn die entsprechenden PKCS11-Mechanismen von der zugrunde liegenden PKCS11-Library unterstützt werden.
Siehe JDK-8080462
Weitere Hinweise: Neue Prüfungen für Vertrauensankerzertifikate
Es wurden neue Prüfungen hinzugefügt, um sicherzustellen, dass Vertrauensanker CA-Zertifikate sind und ordnungsgemäße Erweiterungen enthalten. Mit Vertrauensankern werden in TLS und signiertem Code verwendete Zertifikatsketten validiert. Vertrauensankerzertifikate müssen eine Basis-Constraint-Erweiterung enthalten, bei der das cA-Feld auf "true" gesetzt ist. Außerdem muss das keyCertSign-Bit festgelegt sein, wenn sie eine Schlüsselverwendungserweiterung aufweisen.
JDK-8230318 (nicht allgemein zugänglich)
Weitere Hinweise: Genaue Übereinstimmung für vertrauenswürdiges TLS-Serverzertifikat erforderlich
Ein TLS-Serverzertifikat muss genau mit einem vertrauenswürdigen Zertifikat im Client übereinstimmen, um beim Aufbau einer TLS-Verbindung als vertrauenswürdig eingestuft zu werden.
JDK-8227758 (nicht allgemein zugänglich)
Weitere Hinweise: LuxTrust Global Root 2-Zertifikat hinzugefügt
Das LuxTrust-Root-Zertifikat wurde zum cacerts-Truststore hinzugefügt
Siehe JDK-8232019
Weitere Hinweise: 4 Amazon-Root-CA-Zertifikate hinzugefügt
Amazon-Root-Zertifikat wurde zum cacerts-Truststore hinzugefügt
Siehe JDK-8233223
Bugfixes: Unterstützung für OpenType-CFF-Schriftarten
Zuvor enthielt Oracle JDK 8 keine OpenType-CFF-Schriftarten (OTF-Schriftarten) in den logischen Standardschriftarten (wie "Dialog" und "SansSerif"). Daher fehlten Glyphen beim Rendern von Text. Im schlimmsten Fall (wenn nur CFF-Schriftarten im System installiert waren) konnte eine Java-Ausnahme ausgelöst werden.
Mehrere Linux-Distributionen waren von diesem Problem betroffen, weil sie CFF-Schriftarten für einige Sprachen benötigten (wie das bei Chinesisch, Japanisch und Koreanisch oft der Fall ist).
Oracle JDK 8 verwendet jetzt diese CFF-Schriftarten, und dieses Problem wurde behoben.
Siehe JDK-8209672
Bugfixes: Besseres Handling von seriellen Filtern
Die Systemeigenschaft jdk.serialFilter kann nur in der Befehlszeile festgelegt werden. Wenn der Filter nicht in der Befehlszeile festgelegt wurde, kann er mit java.io.ObjectInputFilter.Config.setSerialFilter festgelegt werden. Die Einstellung von jdk.serialFilter mit java.lang.System.setProperty hat keine Wirkung.
JDK-8231422 (nicht allgemein zugänglich)

Java-Ablaufdatum

Ablaufdatum für 8u241 ist der 14. April 2020. Java wird ungültig, sobald ein neues Release mit verbesserter Sicherheit verfügbar wird. Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u241) auf Basis eines alternativen Verfahrens am 14. Mai 2020 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren.

Bugfixes

» 8u241-Versionshinweise

Java 8 Update 231 (8u231)

Releasehauptmerkmale

IANA Data 2019b
JDK 8u231 enthält Version 2019b der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.
Neues Feature: Neue Systemeigenschaft "jdk.jceks.iterationCount"
Eine neue Systemeigenschaft wurde eingeführt, um den Wert der Iterationsanzahl für den jceks-Keystore zu steuern. Der Standardwert bleibt bei 200000, aber es können Werte zwischen 10000 und 5000000 angegeben werden. Der Name der neuen Systemeigenschaft lautet jdk.jceks.iterationCount, und der angegebene Wert sollte eine Ganzzahl innerhalb des zulässigen Bereichs sein. Der Standardwert wird verwendet, wenn ein Parsingfehler auftritt.
JDK-8223269 (nicht allgemein zugänglich)
Neues Feature: Neue Sicherheitsereignisse für Java Flight Recorder (JFR)
Im Bereich der Sicherheitsbibliothek wurden vier neue JFR-Ereignisse hinzugefügt. Diese Ereignisse sind standardmäßig deaktiviert und können über die JFR-Konfigurationsdateien oder über JFR-Standardoptionen aktiviert werden.
Siehe JDK-8148188
Entfernte Features und Optionen: T2K-Rasterizer und ICU-Layout-Engine aus JavaFX wurden entfernt
Der T2K-Rasterizer und die ICU-Layout-Engine wurden aus JavaFX entfernt.
Siehe JDK-8187147
Weitere Hinweise: [Clientbibliotheken und JavaFX] GTK3 wird jetzt unter Linux/Unix als Standard verwendet
Neuere Versionen von Linux, Solaris und anderen Unix-ähnlichen Desktopumgebungen verwenden GTK3. Dabei wird GTK2 weiterhin unterstützt.
Bisher wurden im JDK standardmäßig die älteren GTK2-Bibliotheken geladen. In diesem Release werden jedoch standardmäßig die GTK3-Bibliotheken geladen. Der Ladevorgang wird normalerweise durch Verwendung des GTK-Look-and-Feels von Swing ausgelöst.
Das alte Verhalten kann durch Verwendung der folgenden Systemeigenschaft wiederhergestellt werden: -Djdk.gtk.version=2.2
Siehe JDK-8222496
Sonstige Hinweise: Veraltete NIST-EC-Kurven aus den TLS-Standardalgorithmen entfernen
Bei dieser Änderung werden veraltete NIST-EC-Kurven aus den standardmäßigen benannten Gruppen entfernt, die während der TLS-Verhandlung verwendet werden. Folgende Kurven werden entfernt: sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1 und secp256k1.
Um diese Kurven erneut zu aktivieren, verwenden Sie die Systemeigenschaft jdk.tls.namedGroups. Die Eigenschaft enthält eine durch Komma getrennte Liste mit in Anführungszeichen gesetzten aktivierten benannten Gruppen in der Reihenfolge ihrer Präferenz. Beispiel:
java -Djdk.tls.namedGroups="secp256r1, secp384r1, secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1" ...
JDK-8228825 (nicht allgemein zugänglich)

Java-Ablaufdatum

Das Ablaufdatum für 8u231 ist der 14. Januar 2020. Java wird ungültig, sobald ein neues Release mit verbesserter Sicherheit verfügbar wird. Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u231) auf Basis eines alternativen Mechanismus am 14. Februar 2020 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren.

Bugfixes

» 8u231-Versionshinweise

Java 8 Update 221 (8u221)

Releasehauptmerkmale

IANA Data 2018i
JDK 8u221 enthält Version 2018i der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.
Neues Feature: Windows Server 2019 wird von der Windows-Betriebssystemerkennung für Hotspots korrekt identifiziert
Vor diesem Fix wurde Windows Server 2019 als "Windows Server 2016" erkannt, wodurch falsche Werte in der Systemeigenschaft os.name und der Datei hs_err_pid erstellt wurden.
Siehe JDK-8211106
Entfernte Features und Optionen: Zwei DocuSign Root-CA-Zertifikate wurden entfernt
Zwei DocuSign Root-CA-Zertifikate sind abgelaufen und wurden aus dem cacerts-Keystore entfernt:
- Aliasname "certplusclass2primaryca [jdk]"
  Distinguished Name: CN=Class 2 Primary CA, O=Certplus, C=FR
- Aliasname "certplusclass3pprimaryca [jdk]"
  Distinguished Name: CN=Class 3P Primary CA, O=Certplus, C=FR
Siehe JDK-8223499
Entfernte Features und Optionen: Zwei Comodo Root-CA-Zertifikate wurden entfernt
Zwei Comodo Root-CA-Zertifikate sind abgelaufen und wurden aus dem cacerts-Keystore entfernt:
- alias name "utnuserfirstclientauthemailca [jdk]"
  Distinguished Name: CN=UTN-USERFirst-Client Authentication and Email, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
- alias name "utnuserfirsthardwareca [jdk]"
  Distinguished Name: CN=UTN-USERFirst-Hardware, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
Siehe JDK-8222136
Entfernte Features und Optionen: T-Systems Deutsche Telekom Root-CA 2-Zertifikat wurde entfernt
Das T-Systems Deutsche Telekom Root-CA 2-Zertifikat ist abgelaufen und wurde aus dem cacerts-Keystore entfernt:
- alias name "deutschetelekomrootca2 [jdk]"
  Distinguished Name: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche Telekom AG, C=DE
Siehe JDK-8222137
Weitere Hinweise: Workaround für Installation von Java Access Bridge
Es ist möglich, dass Java Access Bridge bei der Installation von Java auf einem Windows-System, auf dem eine bereits installierte Version von Java und eine Instanz von JAWS ausgeführt werden, nicht mehr funktioniert. Nach dem Neustart kann es sein, dass die Datei WindowsAccessBridge-64.dll bei 64-Bit-Java-Produkten im Systemverzeichnis (C:\Windows\System32) oder bei 32-Bit-Java-Produkten im von WOW64 verwendeten Systemverzeichnis (C:\Windows\SysWoW64) fehlt.
Damit Java Access Bridge funktioniert, verwenden Sie einen der folgenden Workarounds:
- Stoppen Sie JAWS vor dem Ausführen des Java-Installationsprogramms.
- Deinstallieren Sie die vorhandenen JREs, bevor Sie eine neue Version von Java installieren.
- Deinstallieren Sie die vorhandenen JREs, nachdem die neue Version von Java installiert und der Rechner neu gestartet wurde.
Mit den Workarounds soll vermieden werden, dass vorhandene JREs vom Java-Installationsprogramm deinstalliert werden müssen, während JAWS ausgeführt wird.
JDK-8223293 (nicht allgemein zugänglich)

Java-Ablaufdatum

Das Ablaufdatum für 8u221 ist der 15. Oktober 2019. Java wird ungültig, sobald ein neues Release mit verbesserter Sicherheit verfügbar wird. Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u221) auf Basis eines alternativen Mechanismus am 15. November 2019 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren.

Bugfixes

» 8u221-Versionshinweise

Java 8 Update 211 (8u211)

Releasehauptmerkmale

IANA Data 2018g
JDK 8u211 enthält Version 2018g der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.
Neues Feature: Unterstützung für quadratische Zeichen für neue japanische Ära
Der Codepunkt U+32FF wurde vom Unicode-Konsortium für die Darstellung quadratischer Zeichen für die neue Ära Japans reserviert, die im Mai 2019 beginnt. Relevante Methoden in der Zeichenklasse geben dieselben Eigenschaften wie die vorhandenen Zeichen für die japanische Ära zurück (Beispiel: U+337E für "Meizi"). Nähere Einzelheiten zum Codepunkt finden Sie unter http://blog.unicode.org/2018/09/new-japanese-era.html.
Siehe JDK-8211398
Änderung: GlobalSign-R6-Root-Zertifikat hinzugefügt
Das folgende Root-Zertifikat wurde zum OpenJDK cacerts-Truststore hinzugefügt:
- GlobalSign
  - globalsignrootcar6
    DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R6
JDK-8216577 (nicht allgemein zugänglich)
Änderung: Über Symantec-Root verankerte TLS-Serverzertifikate werden nicht mehr als vertrauenswürdig eingestuft
Von Symantec ausgegebene TLS-Serverzertifikate werden von JDK nicht mehr als vertrauenswürdig eingestuft. Dies entspricht ähnlichen Plänen, die vor Kurzem von Google, Mozilla, Apple und Microsoft angekündigt wurden. Die Liste der betroffenen Zertifikate umfasst Zertifikate von Marken wie GeoTrust, Thawte und VeriSign, die von Symantec verwaltet wurden.
Alle bis einschließlich 16. April 2019 ausgegebenen TLS-Serverzertifikate bleiben bis zu ihrem Ablaufdatum gültig. Nach diesem Datum ausgegebene Zertifikate werden abgelehnt. Auf der Seite zur DigiCert-Unterstützung finden Sie Informationen zum Ersetzen Ihrer Symantec-Zertifikate durch ein DigiCert-Zertifikat (DigiCert hat am 1. Dezember 2017 die Validierung und Ausgabe aller SSL/TLS-Zertifikate der Symantec-Websitesicherheit übernommen).
Von dieser Policy ausgenommen sind TLS-Serverzertifikate, die über eine der beiden unten angegebenen, von Apple verwalteten untergeordneten Certificate Authoritys ausgegeben wurden. Diese werden weiterhin als vertrauenswürdig eingestuft, solange sie am oder vor dem 31. Dezember 2019 ausgegeben wurden.
Siehe JDK-8207258
Änderung: Name der neuen japanischen Ära
Der Platzhaltername "NewEra" für die japanische Ära, die am 1. Mai 2019 begann, wurde durch den von der japanischen Regierung bekanntgegebenen Namen "Reiwa" ersetzt. Anwendungen, die das Singleton der neuen Ära anhand des Platzhalternamens abrufen (JapaneseEra.valueOf("NewEra")), funktionieren nicht mehr.
Siehe JDK-8205432
Änderung: Unterstützung für neue japanische Ära in java.time.chrono.JapaneseEra
Die JapaneseEra-Klasse und ihre Methoden of(int), valueOf(String) und values() wurden näher erläutert, um zukünftige japanische Äras aufzunehmen. Dies umfasst z.B. die Art, in der Singletoninstanzen definiert werden, die zugehörigen Ganzzahlenwerte der Ära usw.
Siehe JDK-8212941

Java-Ablaufdatum

Das Ablaufdatum für 8u211 ist der 16. Juli 2019. Java wird ungültig, sobald ein neues Release mit verbesserter Sicherheit verfügbar wird. Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u211) auf Basis eines alternativen Mechanismus am 16. August 2019 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren.

Bugfixes

Dieses Release enthält Fixes zum Schließen von Sicherheitslücken. Weitere Informationen finden Sie in Oracle Java SE - Kritisches Patchupdate-Advisory. Eine Liste der in diesem Release enthaltenen Bugfixes finden Sie auf der Seite mit Bugfixes für JDK 8u211.

» 8u211-Versionshinweise

Java 8 Update 201 (8u201)

Releasehauptmerkmale

IANA Data 2018e
JDK 8u201 enthält Version 2018e der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.
Änderung: TLS-Cipher-Suites "anon" und "NULL" sind deaktiviert
Die TLS-Cipher-Suites "anon" (anonym) und "NULL" wurden der Sicherheitseigenschaft jdk.tls.disabledAlgorithms hinzugefügt und sind nun standardmäßig deaktiviert.
Siehe JDK-8211883
Änderung: jarsigner gibt an, wann ein Zeitstempel abläuft
Das jarsigner-Tool zeigt nun mehr Informationen zur Gültigkeitsdauer einer JAR mit Zeitstempel an. Neue Warn- und Fehlermeldungen werden angezeigt, wenn ein Zeitstempel abgelaufen ist oder innerhalb eines Jahres abläuft.
Siehe JDK-8191438

Java-Ablaufdatum

Ablaufdatum für 8u201 ist der 16. April 2019. Java wird ungültig, sobald ein neues Release mit verbesserter Sicherheit verfügbar wird. Bei Systemen, die nicht auf Oracle Server zugreifen können, läuft dieses JRE (Version 8u201) auf Basis eines alternativen Verfahrens am 16. Mai 2019 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren.

Bugfixes

» 8u201-Versionshinweise

Java 8 Update 191 (8u191)

Releasehauptmerkmale

IANA Data 2018e
JDK 8u191 enthält Version 2018e der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.
Änderung: Zentrales Dateisystemverzeichnis für Datei usagetracker.properties geändert
In Windows wurde das Dateisystemverzeichnis für die Datei usagetracker.properties von %ProgramData%\Oracle\Java\ nach %ProgramFiles%\Java\conf verschoben.
Für Linux, Solaris oder macOS wurde keine Änderung am Dateipfad vorgenommen. JDK-8204901 (nicht allgemein zugänglich)
Änderung: Alle DES-TLS-Cipher-Suites deaktiviert
DES-basierte TLS-Cipher-Suites werden als veraltet betrachtet und dürfen nicht mehr verwendet werden. DES-basierte Cipher Suites wurden in der SunJSSE-Implementierung standardmäßig deaktiviert, indem die ID "DES" zur Sicherheitseigenschaft jdk.tls.disabledAlgorithms hinzugefügt wurde. Diese Cipher Suites können reaktiviert werden, indem "DES" aus der Sicherheitseigenschaft jdk.tls.disabledAlgorithms in der java.security-Datei entfernt wird oder indem die Methode Security.setProperty() dynamisch aufgerufen wird. In beiden Fällen müssen die DES-basierten Cipher Suites nach dem erneuten Aktivieren von DES über die Methode SSLSocket.setEnabledCipherSuites() oder SSLEngine.setEnabledCipherSuites() zur Liste der aktivierten Cipher Suites hinzugefügt werden.
Beachten Sie, dass DES40_CBC-Suites (jedoch nicht alle DES-Suites) vor dieser Änderung über die Sicherheitseigenschaft jdk.tls.disabledAlgorithms deaktiviert wurden.
Siehe JDK-8208350
Änderung: Mehrere Root-CAs von Symantec wurden entfernt
Die folgenden Root-Zertifikate von Symantec werden nicht mehr verwendet und wurden entfernt:
- Symantec
  - equifaxsecureca
    DN: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
  - equifaxsecureglobalebusinessca1
    DN: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US
  - equifaxsecureebusinessca1
    DN: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US
  - verisignclass1g3ca
    DN: CN=VeriSign Class 1 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
  - verisignclass2g3ca
    DN: CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
  - verisignclass1g2ca
    DN: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
  - verisignclass1ca
    DN: OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
Siehe JDK-8191031
Änderung: Baltimore Cybertrust Code Signing-CA wurde entfernt
Das folgende Baltimore CyberTrust Code Signing-Root-Zertifikat wird nicht mehr verwendet und wurde entfernt:
- baltimorecodesigningca
  DN: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE
Siehe JDK-8189949
Bugfix:LDAPS-Kommunikationsfehler
Für Anwendungscode, der LDAPS mit einem Socket-Verbindungstimeout <= 0 (Standardwert) verwendet und mit dem CPU vom Juli 2018 (8u181, 7u191 und 6u201) ausgeführt wird, kann beim Herstellen der Verbindung eine Ausnahme auftreten.
Die obersten Frames aus den Ausnahme-Stacktraces von Anwendungen, in denen derartige Probleme auftreten, können wie folgt aussehen:
javax.naming.ServiceUnavailableException: ; socket closed
at com.sun.jndi.ldap.Connection.readReply(Unknown Source)
at com.sun.jndi.ldap.LdapClient.ldapBind(Unknown Source) ...
Das Problem wurde behoben, und der Fix wird in den folgenden Releases bereitgestellt:
- 8u181
- 7u191
Siehe JDK-8211107

Java-Ablaufdatum

Das Ablaufdatum für 8u191 ist der 15. Januar 2019. Java wird ungültig, sobald ein neues Release mit verbesserter Sicherheit verfügbar wird. Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u191) auf Basis eines alternativen Mechanismus am 15. Februar 2019 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren.

Bugfixes

» 8u191-Versionshinweise

Java 8 Update 181 (8u181)

Releasehauptmerkmale

IANA Data 2018e
JDK 8u181 enthält Version 2018e der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.
Entferntes Feature: Java DB wurde entfernt
Java DB (auch als Apache Derby bezeichnet) wurde in diesem Release entfernt.
Es wird empfohlen, dass Sie die aktuelle Apache Derby-Version hier direkt vom Apache-Projekt herunterladen:
https://db.apache.org/derby
JDK-8197871 (nicht allgemein zugänglich)
Änderung: Verbesserte LDAP-Unterstützung
Die Endpunktidentifizierung wurde für LDAPS-Verbindungen aktiviert.
Um die Robustheit von LDAPS-Verbindungen (sicheres LDAP über TLS) zu verbessern, wurden Algorithmen zur Endpunktidentifizierung standardmäßig aktiviert.
Beachten Sie, dass einige Anwendungen, die sich zuvor erfolgreich mit einem LDAPS-Server verbinden konnten, unter Umständen nicht mehr dazu in der Lage sind. Diese Anwendungen können die Endpunktidentifizierung gegebenenfalls mit einer neuen Systemeigenschaft deaktivieren: com.sun.jndi.ldap.object.disableEndpointIdentification.
Definieren Sie diese Systemeigenschaft (bzw. stellen Sie sie auf true ein), um Algorithmen zur Endpunktidentifizierung zu deaktivieren.
JDK-8200666 (nicht allgemein zugänglich)
Änderung: Besseres Stack-Walking
Neue Zugriffsprüfungen wurden bei der Objekterstellungsphase der Deserialisierung hinzugefügt. Gewöhnliche Verwendungen der Deserialisierung sollten davon nicht betroffen sein. Auf reflektive Frameworks, die JDK-interne APIs verwenden, kann dies jedoch Auswirkungen haben. Die neuen Prüfungen können gegebenenfalls deaktiviert werden, indem Sie die Systemeinstellung jdk.disableSerialConstructorChecks auf "true" setzen. Dazu müssen Sie das Argument -Djdk.disableSerialConstructorChecks=true zur Java-Befehlszeile hinzufügen.
JDK-8197925 (nicht allgemein zugänglich)
Bugfix: JVM-Absturz bei G1 GC
Eine "klass", die bei der nebenläufigen Markierung von G1 als nicht erreichbar eingestuft wurde, kann im ClassLoaderData/SystemDictionary nachgeschlagen werden. Die zugehörigen Felder zu _java_mirror oder _class_loader können in einer Root oder einem anderen erreichbaren Objekt gespeichert werden, sodass das Objekt wieder live ist. Wenn eine "klass" auf diese Weise wiederhergestellt wird, muss der SATB-Teil von G1 darüber benachrichtigt werden. Andernfalls wird diese "klass" bei der Remarking-Phase der nebenläufigen Markierung fälschlicherweise entladen.
Siehe JDK-8187577
Bugfix: Bessere Stabilität mit älteren NUMA-Librarys (-XX+UseNuma)
Ein Fix in JDK 8 Update 152 hat zu einer Regression geführt, aufgrund derer die HotSpot-JVM beim Hochfahren abstürzen könnte, wenn das UseNUMA-Kennzeichen auf Linux-Systemen mit libnuma-Versionen vor 2.0.9 verwendet wird. Dieses Problem wurde behoben.
Siehe JDK-8198794

Java-Ablaufdatum

Das Ablaufdatum für 8u181 ist der 16. Oktober 2018. Java wird ungültig, sobald ein neues Release mit verbesserter Sicherheit verfügbar wird. Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u181) auf Basis eines alternativen Mechanismus am 16. November 2018 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren.

Bugfixes

» 8u181-Versionshinweise

Java 8 Update 171 (8u171)

Releasehauptmerkmale

IANA Data 2018c
JDK 8u171 enthält Version 2018c der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.
Neues Feature: Verbesserte KeyStore-Mechanismen
Eine neue Sicherheitseigenschaft mit dem Namen jceks.key.serialFilter wurde eingeführt. Falls dieser Filter konfiguriert wird, verwendet der JCEKS-KeyStore ihn bei der Deserialisierung des in SecretKeyEntry gespeicherten verschlüsselten Schlüsselobjekts. Falls der Filter nicht konfiguriert wird oder sein Ergebnis UNDECIDED lautet (z.B. keine der Muster stimmen überein), wird der von jdk.serialFilter konfigurierte Filter herangezogen.
Wird auch die Systemeigenschaft jceks.key.serialFilter angegeben, ersetzt sie den hier definierten Sicherheitseigenschaftswert.
Das Filtermuster verwendet dasselbe Format wie jdk.serialFilter. Das Standardmuster lässt java.lang.Enum, java.security.KeyRep, java.security.KeyRep$Type und javax.crypto.spec.SecretKeySpec zu, lehnt jedoch alle anderen Typen ab.
Kunden, die einen SecretKey gespeichert haben, der nicht in die oben genannten Typen serialisiert wird, müssen den Filter so ändern, dass der Schlüssel extrahiert werden kann.
JDK-8189997 (nicht allgemein zugänglich)
Neues Feature: Systemeigenschaft zum Deaktivieren des Trackings für die letzte JRE-Verwendung
Eine neue Systemeigenschaft jdk.disableLastUsageTracking wurde eingeführt, um das Tracking für die letzte JRE-Verwendung für eine gestartete VM zu deaktivieren. Diese Eigenschaft kann in der Befehlszeile mit -Djdk.disableLastUsageTracking=true oder -Djdk.disableLastUsageTracking festgelegt werden. Nachdem diese Systemeigenschaft festgelegt wurde, wird das Tracking für die letzte JRE-Verwendung unabhängig vom Eigenschaftswert com.oracle.usagetracker.track.last.usage, der in usagetracker.properties festgelegt wurde, deaktiviert.
JDK-8192039 (nicht allgemein zugänglich)
Hinweis: CipherOutputStream-Nutzung
Die Spezifikation zu javax.crypto.CipherOutputStream gibt jetzt deutlich an, dass BadPaddingException und andere durch nicht erfolgreiche Integritätsprüfungen bei der Entschlüsselung ausgelöste Ausnahmen mit dieser Klasse abgefangen werden. Diese Ausnahmen werden nicht erneut ausgelöst. Der Kunde wird also nicht darüber informiert, dass Integritätsprüfungen nicht erfolgreich waren. Aufgrund dieses Verhaltens eignet sich diese Klasse möglicherweise nicht zur Verwendung mit einer Entschlüsselung im authentifizierten Betriebsmodus (z.B. GCM), wenn die Anwendung eine explizite Benachrichtigung bei nicht erfolgreicher Authentifizierung voraussetzt. Diese Anwendungen können die Cipher-API als eine direkte Alternative zu dieser Klasse verwenden.
JDK-8182362 (nicht allgemein zugänglich)
Änderung: Zusätzliches TeliaSonera-Root-Zertifikat
"TeliaSonera Root CA v1" wurde zum cacerts-Keystore hinzugefügt.
JDK-8190851 (nicht allgemein zugänglich)
Änderung: Mit EC-Schlüsseln mit weniger als 224 Bit signierte XML-Signaturen wurden deaktiviert
Zur Verbesserung der SSL/TLS-Verbindungsstärke wurden 3DES-Cipher Suites in den SSL/TLS-Verbindungen in JDK über die Sicherheitseigenschaft jdk.tls.disabledAlgorithms deaktiviert.
JDK-8175075 (nicht allgemein zugänglich)
Bugfix: Serverseitiges HTTP-Tunneling für RMI-Verbindungen wurde deaktiviert
Serverseitiges HTTP-Tunneling für RMI-Verbindungen wird in diesem Release standardmäßig deaktiviert. Dieses Verhalten kann durch das Setzen der Laufzeiteigenschaft sun.rmi.server.disableIncomingHttp auf false rückgängig gemacht werden. Hinweis: Verwechseln Sie dies nicht mit der Eigenschaft sun.rmi.server.disableHttp, die das clientseitige HTTP-Tunneling deaktiviert und standardmäßig auf false gesetzt ist.
JDK-8193833 (nicht allgemein zugänglich)

Java-Ablaufdatum

Das Ablaufdatum für 8u171 ist der 17. Juli 2018. Java wird ungültig, sobald ein neues Release mit verbesserter Sicherheit verfügbar wird. Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u171) auf Basis eines alternativen Mechanismus am 17. August 2018 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren.

Bugfixes

Dieses Release enthält Fixes zum Schließen von Sicherheitslücken. Weitere Informationen finden Sie in Oracle Java SE - Kritisches Patchupdate-Advisory. Eine ausführlichere Liste der in diesem Release enthaltenen Bugfixes finden Sie auf der Seite Bugfixes für JDK 8u171.

» 8u171-Versionshinweise

Java 8 Update 161 (8u161)

Releasehauptmerkmale

IANA Data 2017c
JDK 8u161 enthält Version 2017c der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.
Neues Feature: Unterstützung für eine DHE-Größe von bis zu 8192 Bit und eine DSA-Größe von bis zu 3072 Bit
Die JDK-Sicherheitsprovider bieten jetzt Unterstützung für eine Generierung von DiffieHellman- und DSA-Parametern mit einer Größe von bis zu 3072 Bit, für im Voraus berechnete DiffieHellman-Parameter mit bis zu 8192 Bit sowie für im Voraus berechnete DSA-Parameter mit bis zu 3072 Bit.
Siehe JDK-8072452
Neues Feature: Negotiated Finite Field Diffie-Hellman Ephemeral-Parameter für TLS
Die JDK SunJSSE-Implementierung unterstützt jetzt den in RFC 7919 definierten TLS FFDHE-Mechanismus. Wenn ein Server die TLS-Erweiterung supported_groups oder die benannten Gruppen in der Erweiterung nicht verarbeiten kann, können Anwendungen entweder die unterstützten Gruppennamen mit jdk.tls.namedGroups anpassen oder die FFDHE-Mechanismen deaktivieren, indem sie die Systemeigenschaft jsse.enableFFDHEExtension auf false einstellen.
Siehe JDK-8140436
Neues Feature: Zusätzliche IDL-Stub-Typprüfungen zur Methode org.omg.CORBA.ORBstring_to_object hinzufügen
Anwendungen, die org.omg.CORBA.ORB.string_to_object entweder explizit oder implizit aufrufen und die Integrität des am Aufruffluss ORB::string_to_object beteiligten IDL-Stub-Typs bewahren möchten, müssen eine zusätzliche IDL-Stub-Typprüfung angeben. Dieses Feature ist optional und wird nicht standardmäßig aktiviert.
Um die zusätzliche Typprüfung zu nutzen, wird die Liste der zulässigen IDL-Schnittstellenklassennamen der IDL-Stub-Klassen über eine der folgenden Methoden konfiguriert:
- Durch Angabe der Sicherheitseigenschaft com.sun.CORBA.ORBIorTypeCheckRegistryFilter in der Datei conf/security/java.security in Java SE 9 bzw. in jre/lib/security/java.security in Java SE 8 und früheren Versionen.
- Durch Angabe der Systemeigenschaft com.sun.CORBA.ORBIorTypeCheckRegistryFilter mit der Liste der Klassen. Wenn die Systemeigenschaft festgelegt wird, setzt ihr Wert die entsprechende Eigenschaft in der java.security-Konfiguration außer Kraft.
Wenn die Eigenschaft com.sun.CORBA.ORBIorTypeCheckRegistryFilter nicht festgelegt ist, wird die Typprüfung nur anhand eines Satzes von Klassennamen der IDL-Schnittstellentypen ausgeführt, die den integrierten IDL-Stub-Klassen entsprechen.
JDK-8160104 (nicht allgemein zugänglich)
Änderung: RSA-Public-Key-Validierung
In 8u16 weist die RSA-Implementierung im SunRsaSign-Provider alle RSA-Public Keys zurück, die einen Exponenten besitzen, der nicht in dem von PKCS#1 Version 2.2 definierten zulässigen Bereich liegt. Diese Änderung betrifft JSSE-Verbindungen sowie Anwendungen, die auf JCE aufbauen.
JDK-8174756 (nicht allgemein zugänglich)
Änderung: Einschränkung von Diffie-Hellman-Schlüsseln mit weniger als 1024 Bit
Diffie-Hellman-Schlüssel mit weniger als 1024 Bit werden in der Praxis als zu schwach angesehen und sollten in SSL/TLS/DTLS-Verbindungen standardmäßig eingeschränkt werden. Dementsprechend wurden Diffie-Hellman-Schlüssel mit weniger als 1024 Bit standardmäßig deaktiviert, indem der Sicherheitseigenschaft "jdk.tls.disabledAlgorithms" in der java.security-Datei "DH keySize < 1024" hinzugefügt wurde. Administratoren können die Sicherheitseigenschaft ("jdk.tls.disabledAlgorithms") aktualisieren und kleinere Schlüsselgrößen zulassen (z.B. durch Festlegen von "DH keySize < 768"). Dies wird jedoch nicht empfohlen.
JDK-8148108 (nicht allgemein zugänglich)
Änderung: Standardschlüsselgröße für Provider wird aktualisiert
Mit dieser Änderung werden JDK-Provider aktualisiert, sodass anstelle von 1024 Bit 2048 Bit als Standardschlüsselgröße für DSA verwendet wird, wenn Anwendungen die Objekte java.security.KeyPairGenerator und java.security.AlgorithmParameterGenerator nicht explizit mit einer Schlüsselgröße initialisiert haben.
Bei Auftreten von Kompatibilitätsproblemen können vorhandene Anwendungen für die in JDK-8181048 eingeführte Systemeigenschaft jdk.security.defaultKeySize den Algorithmus und die gewünschte Standardschlüsselgröße festlegen.
JDK-8178466 (nicht allgemein zugänglich)

Java-Ablaufdatum

Ablaufdatum für 8u161 ist der 17. April 2018. Java wird ungültig, sobald ein neues Release mit verbesserter Sicherheit verfügbar wird. Bei Systemen, die nicht auf Oracle Server zugreifen können, läuft diese JRE (Version 8u161) auf Basis eines alternativen Verfahrens am 17. Mai 2018 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren.

Bugfixes

» 8u161-Versionshinweise

Java 8 Update 151 (8u151)

Releasehauptmerkmale

IANA Data 2017b
JDK 8u151 enthält Version 2017b der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.
Zertifikatsänderungen: Entzogenes Swisscom-Root-Zertifikat "swisscomrootevca2" wurde entfernt
Ein Swisscom-Root-Zertifikat wurde von Swisscom entzogen und entfernt: Swisscom Root EV CA 2 alias: "swisscomrootevca2 [jdk]" DN: CN=Swisscom Root EV CA 2, OU=Digital Certificate Services, O=Swisscom, C=ch
JDK-8186330 (nicht allgemein zugänglich)
Neue Features Neue Sicherheitseigenschaft zur Kontrolle der Kryptografie-Policy
In diesem Release wird ein neues Feature eingeführt, bei dem die im JDK verwendeten JCE Jurisdiction Policy-Dateien mit einer neuen Sicherheitseigenschaft kontrolliert werden können. In älteren Releases mussten die JCE Jurisdiction-Dateien separat heruntergeladen und installiert werden, damit im JDK unbegrenzte Kryptografie verwendet werden konnte. Das Herunterladen und Installieren ist jetzt nicht mehr erforderlich. Um unbegrenzte Kryptografie zu ermöglichen, kann die neue crypto.policy-Sicherheitseigenschaft verwendet werden. Wenn die neue Sicherheitseigenschaft (crypto.policy) in der java.security-Datei festgelegt ist oder über den Security.setProperty()-Aufruf dynamisch festgelegt wurde, bevor das JCE Framework initialisiert wurde, wird diese Einstellung berücksichtigt. Standardmäßig ist die Eigenschaft nicht definiert. Wenn die Eigenschaft nicht definiert ist und die älteren JCE Jurisdiction-Dateien nicht im Legacy-Verzeichnis lib/security vorhanden sind, bleibt die Standardverschlüsselungsebene auf "Begrenzt". Um das JDK so zu konfigurieren, dass unbegrenzte Kryptografie verwendet wird, legen Sie für crypto.policy den Wert "Unbegrenzt" fest. Weitere Informationen finden Sie in der Datei java.security, die mit diesem Release ausgeliefert wird.
Hinweis: Bei Solaris wird empfohlen, die alten SVR4-Packages zu entfernen, bevor Sie die neuen JDK-Updates installieren. Wenn Sie ein SVR4-basiertes Upgrade (ohne Deinstallation der alten Packages) auf einem JDK-Release vor 6u131, 7u121 oder 8u111 vornehmen, müssen Sie die neue crypto.policy-Sicherheitseigenschaft in der Datei java.security festlegen.

Die alten JCE Jurisdiction-Dateien verbleiben in <java-home>/lib/security. Möglicherweise erfüllen sie nicht die neuesten JAR-Sicherheitsstandards für Signaturen, die in 6u131, 7u121, 8u111 und späteren Updates aktualisiert wurden. Wenn die alten Dateien verwendet werden, wird möglicherweise eine Exception wie die folgende angezeigt:

Caused by: java.lang.SecurityException: Jurisdiction policy files are not signed by trusted signers! at javax.crypto.JceSecurity.loadPolicies(JceSecurity.java:593) at javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:524)
Siehe JDK-8157561
Änderungen Refactoring vorhandener Provider, sodass auf dieselben Konstanten für Standardwerte für die Schlüssellänge verwiesen wird
Im Zusammenhang mit diesem Problem wurden zwei wichtige Änderungen vorgenommen:
1. Eine neue Systemeigenschaft wurde eingeführt, mit der Benutzer die Standardschlüsselgröße konfigurieren können, die von den JDK-Provider-Implementierungen für KeyPairGenerator und AlgorithmParameterGenerator verwendet werden. Diese Eigenschaft heißt "jdk.security.defaultKeySize", und der Wert dieser Eigenschaft entspricht einer Liste von durch Komma getrennten Einträgen. Jeder Eintrag besteht aus einem Algorithmusnamen (ohne Berücksichtigung der Groß-/Kleinschreibung) und der entsprechenden Standardschlüsselgröße (in Dezimalangabe), durch ":" getrennt. Leerzeichen werden ignoriert.
Standardmäßig weist diese Eigenschaft keinen Wert auf, und JDK-Provider verwenden ihre eigenen Standardwerte. Einträge, deren Algorithmusname nicht erkannt wird, werden ignoriert. Wenn es sich bei der angegebenen Standardschlüsselgröße nicht um eine Dezimalganzzahl handelt, die geparst werden kann, wird der betreffende Eintrag ebenfalls ignoriert.
1. Die DSA-KeyPairGenerator-Implementierung des SUN-Providers implementiert nicht mehr java.security.interfaces.DSAKeyPairGenerator. In Anwendungen, die das DSA-KeyPairGenerator-Objekt des SUN-Providers in java.security.interfaces.DSAKeyPairGenerator konvertieren, kann die Systemeigenschaft "jdk.security.legacyDSAKeyPairGenerator" festgelegt werden. Wenn der Wert dieser Eigenschaft "true" ist, gibt der SUN-Provider ein DSA-KeyPairGenerator-Objekt zurück, das die java.security.interfaces.DSAKeyPairGenerator-Schnittstelle implementiert. Diese ältere Implementierung verwendet denselben Standardwert wie von Javadoc in der Schnittstelle angegeben.
Standardmäßig weist diese Eigenschaft keinen Wert auf, und der SUN-Provider gibt ein DSA-KeyPairGenerator-Objekt zurück, das die oben genannte Schnittstelle nicht implementiert. Deshalb kann der SUN-Provider seinen eigenen providerspezifischen Standardwert bestimmen, der in der java.security.KeyPairGenerator-Klasse oder von der Systemeigenschaft "jdk.security.defaultKeySize" (falls festgelegt) angegeben wird.
JDK-8181048 (nicht allgemein zugänglich)

Java-Ablaufdatum

Das Ablaufdatum für 8u151 ist der 16. Januar 2018. Java wird ungültig, sobald ein neues Release mit verbesserter Sicherheit verfügbar wird. Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u151) auf Basis eines alternativen Mechanismus am 16. Februar 2018 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren.

Bugfixes

» 8u151-Versionshinweise

Java 8 Update 144 (8u144)

Releasehauptmerkmale

IANA Data 2017b
JDK 8u144 enthält Version 2017b der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.
Bugfix: java.util.zip.ZipFile.getEntry() gibt die ZipEntry-Instanz jetzt immer mit einem auf / endenden Eintragsnamen für den Verzeichniseintrag zurück.
Gemäß API-Dokumentation für java.util.zip.ZipEntry ist ein Verzeichniseintrag als Eintrag mit einem auf / endenden Namen definiert. In früheren JDK-Releases gibt java.util.zip.ZipFile.getEntry(String entryName) jedoch möglicherweise eine ZipEntry-Instanz mit einem nicht auf / endenden Eintragsnamen für einen vorhandenen ZIP-Verzeichniseintrag zurück, wenn das übergebene Argument entryName nicht auf / endet und die ZIP-Datei einen übereinstimmenden ZIP-Verzeichniseintrag namens entryName + / enthält. Ab diesem Release endet der Name der von java.util.zip.ZipFile.getEntry() zurückgegebenen ZipEntry-Instanz für jeden ZIP-Verzeichniseintrag immer auf /
Um das vorherige Verhalten wiederherzustellen, setzen Sie die Systemeigenschaft jdk.util.zip.ensureTrailingSlash auf "false".

Mit dieser Änderung wird eine in JDK 8u141 eingeführte Regression behoben, durch die das Überprüfen signierter JARs das Laden einiger WebStart-Anwendungen verhindert hat.
Siehe JDK-8184993

Java-Ablaufdatum

Das Ablaufdatum für 8u144 ist der 17. Oktober 2017. Java wird ungültig, sobald ein neues Release mit verbesserter Sicherheit verfügbar wird. Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u144) auf Basis eines alternativen Mechanismus am 17. November 2017 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren.

Bugfixes

» 8u144-Versionshinweise

Java 8 Update 141 (8u141)

Releasehauptmerkmale

IANA Data 2017b
JDK 8u141 enthält Version 2017b der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.
Zertifikatsänderungen: Neue Let's Encrypt-Zertifikate wurden zu Root-CAs hinzugefügt.
Ein neues Root-Zertifikat wurde hinzugefügt:
ISRG Root X1 alias: letsencryptisrgx1 DN: CN=ISRG Root X1, O=Internet Security Research Group, C=US
JDK-8177539 (nicht allgemein zugänglich)
JMX-Diagnoseverbesserungen
com.sun.management.HotSpotDiagnostic::dumpHeap-API wurde geändert, um IllegalArgumentException auszulösen, wenn der angegebene Dateiname nicht mit dem Suffix ".hprof" endet. Vorhandene Anwendungen, die keinen Dateinamen mit der Erweiterung ".hprof" haben, werden mit dem Fehler IllegalArgumentException nicht erfolgreich ausgeführt. In diesem Fall können die Anwendungen entweder die Ausnahme verarbeiten oder das alte Verhalten wiederherstellen, indem sie die Systemeigenschaft 'jdk.management.heapdump.allowAnyFileSuffix' auf "true" einstellen.
JDK-8176055 (nicht allgemein zugänglich)
Strengere Sicherheitsprüfungen beim Verarbeiten von WSDL-Dateien durch das wsimport-Tool
Das wsimport-Tool wurde geändert, um DTDs in Webservicebeschreibungen nicht zuzulassen, insbesondere:
- DOCTYPE-Deklaration ist in Dokumenten nicht zulässig
- Externe allgemeine Entitys sind nicht standardmäßig enthalten
- Externe Parameterentitys sind nicht standardmäßig enthalten
- Externe DTDs werden vollständig ignoriert
So stellen Sie das vorherige Verhalten wieder her:
- Setzen Sie die Systemeigenschaft com.sun.xml.internal.ws.disableXmlSecurity auf "true"
- Befehlszeilenoption –disableXmlSecurity des wsimport-Tools verwenden
  HINWEIS: JDK 7- und JDK 6-Unterstützung für diese Option in wsimport wird über ein Patchrelease nach dem CPU im Juli bereitgestellt
JDK-8182054 (nicht allgemein zugänglich)
Die benutzerdefinierte HostnameVerifier-Schnittstelle aktiviert die SNI-Erweiterung
Frühere Releases der JDK 8-Updates haben in der TLS ClientHello-Phase nicht immer die Server Name Indication-(SNI-)Erweiterung gesendet, wenn eine benutzerdefinierte Hostnamenverifizierung verwendet wurde. Diese Verifizierung wird mit der setHostnameVerifier(HostnameVerifier v)-Methode in HttpsURLConnection festgelegt. Durch den Fix wird der Servername nun im ClientHello-Body gesendet.
Siehe JDK-8144566
Verbesserte Prüfung der Algorithmus-Constraints
Um die Verwendung schwacher Algorithmen in Situationen, wo sie weniger gut geschützt sind, einzuschränken, wurden zusätzliche Features bei der Konfiguration der Sicherheitseigenschaften jdk.certpath.disabledAlgorithms und jdk.jar.disabledAlgorithms in der Datei java.security hinzugefügt.
jdk.certpath.disabledAlgorithms: Die certpath-Eigenschaft enthält die meisten Änderungen. Bisher war sie auf zwei Constraint-Typen begrenzt: entweder eine vollständige Deaktivierung eines Algorithmus nach Namen oder eine vollständige Deaktivierung eines Algorithmus nach Schlüsselgröße bei der Prüfung von Zertifikaten, Zertifikatsketten und Zertifikatsignaturen. Auf diese Weise werden Konfigurationen erstellt, die absolut und wenig flexibel in der Verwendung sind. Für mehr Flexibilität beim Zulassen und Ablehnen von Zertifikaten wurden drei neue Constraints hinzugefügt.

"jdkCA" überprüft die Endung der Zertifikatskette hinsichtlich der cacerts-Datei. Bei "SHA1 jdkCA". Die Zertifikatskette wird auf die Verwendung von "SHA1" geprüft, aber um abgelehnt zu werden, muss die Kette an einem markierten Vertrauensanker im Cacerts Keystore enden. Dies ist nützlich für Organisationen mit eigenen privaten CAs, die der SHA1-Verwendung mit einem eigenen Vertrauensanker vertrauen, aber Zertifikatsketten mit einem öffentlichen CA aus der Verwendung von SHA1 ausschließen möchten.

"denyAfter" prüft, ob das angegebene Datum vor dem aktuellen Datum oder dem PKIXParameter-Datum liegt. Bei "SHA1 denyAfter 2018-01-01" kann ein Zertifikat mit SHA1 vor 2018 verwendet werden. Nach diesem Datum wird das Zertifikat jedoch abgelehnt. Diese Option empfiehlt sich für eine organisationsübergreifende Policy, bei der ein Algorithmus schrittweise bis zum festgelegten Endtermin eingestellt wird. Bei signierten JAR-Dateien wird das Datum mit dem TSA-Zeitstempel verglichen. Das Datum wird in GMT angegeben.

"usage" überprüft den angegebenen Algorithmus hinsichtlich einer bestimmten Verwendung. Diese Option empfiehlt sich, wenn das Deaktivieren eines Algorithmus für alle Verwendungstypen nicht praktikabel ist. Drei Verwendungstypen können angeben werden:
- "TLSServer" schränkt den Algorithmus in den TLS-Serverzertifikatsketten ein, wenn die Serverauthentifizierung als Client ausgeführt wird.
- "TLSClient" schränkt den Algorithmus in den TLS-Serverzertifikatsketten ein, wenn die Clientauthentifizierung als Server ausgeführt wird.
- "SignedJAR" schränkt die Algorithmen in Zertifikaten der signierten JAR-Dateien ein. Der Verwendungstyp folgt auf das Schlüsselwort. Mehrere Verwendungstypen können mit einem Leerzeichen als Begrenzungszeichen angegeben werden.
  Beispiel: Mit "SHA1 usage TLSServer TLSClient" werden SHA1-Zertifikate für TLSServer- und TLSClient-Vorgänge nicht zugelassen, SignedJars werden jedoch zugelassen
All diese Constraints können mithilfe des Begrenzungszeichens "&" kombiniert werden, um einen Algorithmus einzuschränken. Beispiel: Um SHA1-Zertifikatsketten, die bei markierten Vertrauensankern enden, nur für TLSServer-Vorgänge zu deaktivieren, muss der Constraint "SHA1 jdkCA & usage TLSServer" lauten.

jdk.jar.disabledAlgorithms: Ein zusätzlicher Constraint wurde zu dieser .jar-Eigenschaft hinzugefügt, um JAR-Manifestalgorithmen einzuschränken.

"denyAfter" prüft Algorithmus-Constraints auf Manifestdigestalgorithmen innerhalb einer signierten JAR-Datei. Das im Constraint angegebene Datum wird mit dem TSA-Zeitstempel der signierten JAR-Datei verglichen. Wenn kein Zeitstempel vorhanden ist oder der Zeitstempel am bzw. nach dem angegebenen Datum liegt, wird die signierte JAR-Datei als unsigniert behandelt. Wenn der Zeitstempel vor dem angegebenen Datum liegt, wird die JAR-Datei als signierte JAR-Datei ausgeführt. Syntax für die Einschränkung von SHA1 in nach dem 1. Januar 2018 signierten JAR-Dateien: "SHA1 denyAfter 2018-01-01". Es gilt dieselbe Syntax wie für die certpath-Eigenschaft, jedoch wird durch diese Eigenschaft keine Zertifikatsprüfung ausgeführt.
Siehe JDK-8176536

Java-Ablaufdatum

Das Ablaufdatum für 8u141 ist der 17. Oktober 2017. Java wird ungültig, sobald ein neues Release mit verbesserter Sicherheit verfügbar wird. Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u141) auf Basis eines alternativen Mechanismus am 17. November 2017 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von JRE durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren.

Bugfixes

» 8u141-Versionshinweise

Java 8 Update 131 (8u131)

Releasehauptmerkmale

IANA Data 2016j
JDK 8u131 enthält Version 2016j der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.
Bugfix: Einführung eines neuen Modells zur Anordnung von Fenstern
Das AWT-Framework verwendete auf der OS X-Plattform native Services, um Eltern/Kind-Beziehungen für Fenster zu implementieren. Hierdurch wurden negative visuelle Effekte verursacht, insbesondere in Umgebungen mit mehreren Monitoren. Um die Nachteile dieses Ansatzes zu vermeiden, wurde ein neues Modell zur Anordnung von Fenstern eingeführt, das vollständig auf der JDK-Ebene implementiert wird. Nachfolgend werden die grundlegenden Eigenschaften dieses Modells aufgeführt:
- Ein Fenster wird oberhalb des ihm direkt übergeordneten Fensters platziert.
- Wenn ein Fenster mehrere untergeordnete Fenster hat, werden diese auf der gleichen Ebene platziert. Außerdem wird das Fenster aus der aktiven Fensterkette oberhalb der Fenster angeordnet, die ihm gleichgeordnet sind.
- Die Anordnung darf nicht für Fenster ausgeführt werden, die sich in einem minimierten Zustand oder im Übergang zu einem minimierten Zustand befinden.
Diese Regeln gelten für alle Frames und Dialogfelder in der Fensterhierarchie, die das aktuell fokussierte Fenster enthält. Siehe JDK-8169589
Bugfix: Korrektur von IllegalArgumentException aus TLS-Handshake
Neu ermitteltes Problem im Fix JDK-8173783 kann bei bestimmten TLS-Servern Probleme verursachen. Grund des Problems ist eine IllegalArgumentException, die vom TLS-Handshaker-Code ausgelöst wird:

java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves

Dieses Problem kann auftreten, wenn der Server keine Unterstützung für die Kryptografie elliptischer Kurven bietet, um Felder für die Namenserweiterung elliptischer Kurven verarbeiten zu können (falls vorhanden). Benutzern wird empfohlen, ein Upgrade auf dieses Release durchzuführen. Im Lieferumfang von JDK 7-Updates und späterer JDK-Familien ist der SunEC-Sicherheitsprovider enthalten, der Unterstützung für die Kryptografie elliptischer Kurven bietet. Diese Releases sind nur betroffen, wenn die Sicherheitsprovider geändert werden. Siehe JDK-8173783
MD5 wurde zur Sicherheitseigenschaft jdk.jar.disabledAlgorithms hinzugefügt
In diesem JDK-Release wird eine neue Einschränkung bei der Überprüfung von MD5-signierten JAR-Dateien eingeführt. Wenn die signierte JAR-Datei MD5 verwendet, ignoriert die Signaturverifizierung die Signatur und behandelt die JAR so, als wäre sie unsigniert. Dies kann potenziell bei den folgenden Anwendungstypen auftreten, die signierte JAR-Dateien verwenden:
- Applets oder Web Start-Anwendungen
- Standalone- oder Serveranwendungen, die mit einem aktivierten SecurityManager ausgeführt werden und mit einer Richtliniendatei konfiguriert sind, die Berechtigungen gemäß den Codesignaturgebern der JAR-Datei erteilt.
Die Liste der deaktivierten Algorithmen wird über die Sicherheitseigenschaft jdk.jar.disabledAlgorithms in der Datei java.security kontrolliert. Diese Eigenschaft enthält eine Liste mit deaktivierten Algorithmen und Schlüsselgrößen für kryptografisch signierte JAR-Dateien.

Mit der jarsigner-Binärdatei, die mit diesem JDK geliefert wird, kann geprüft werden, ob ein schwacher Algorithmus oder Schlüssel für die Signatur einer JAR-Datei verwendet wurde. Wenn "jarsigner -verify" für eine JAR-Datei ausgeführt wird, die mit einem schwachen Algorithmus oder Schlüssel signiert wurde, werden weitere Informationen zu dem deaktivierten Algorithmus oder Schlüssel ausgegeben.

Beispiel: Um eine JAR-Datei namens test.jar zu prüfen, verwenden Sie diesen Befehl:

jarsigner -verify test.jar

Wenn die Datei in diesem Beispiel mit einem schwachen Signaturalgorithmus wie MD5withRSA signiert wurde, wird Folgendes ausgegeben:

Die JAR wird als unsigniert behandelt, weil sie mit einem schwachen Algorithmus signiert wurde, der jetzt deaktiviert ist. Führen Sie jarsigner mit der Option -verbose erneut aus, um weitere Einzelheiten zu erhalten.

Weitere Einzelheiten können mit der Option -verbose angezeigt werden:

jarsigner -verify -verbose test.jar

Folgendes wird ausgegeben:
```
 - Signed by "CN=weak_signer" Digest algorithm: MD5 (weak) Signature algorithm: MD5withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key 
```
Um dieses Problem zu beheben, muss die JAR-Datei mit einem stärkeren Algorithmus bzw. einer stärkeren Schlüsselgröße erneut signiert werden. Alternativ können die Einschränkungen rückgängig gemacht werden, indem die anwendbaren schwachen Algorithmen oder Schlüsselgrößen aus jdk.jar.disabledAlgorithms entfernt werden; diese Option wird jedoch nicht empfohlen. Bevor Sie die betroffenen JAR-Dateien erneut signieren, müssen die vorhandenen Signaturen aus der JAR-Datei entfernt werden. Dies kann mit dem ZIP-Utility wie folgt vorgenommen werden:

zip -d test.jar 'META-INF/.SF' 'META-INF/.RSA' 'META-INF/*.DSA'

Prüfen Sie die Oracle JRE and JDK Cryptographic Roadmap unter http://java.com/cryptoroadmap regelmäßig auf geplante Einschränkungen für signierte JAR-Dateien und andere Sicherheitskomponenten. JDK-8171121 (nicht allgemein zugänglich)
Neue Systemeigenschaft zum Steuern des Cachings für HTTP SPNEGO-Verbindung.
Es wird eine neue Systemeigenschaft zum Steuern des Cachings für HTTP SPNEGO (Negotiate/Kerberos)-Verbindungen eingeführt. Diese Systemeigenschaft ist spezifisch für JDK-Implementierungen. Das Caching für HTTP SPNEGO-Verbindungen bleibt standardmäßig aktiviert. Wenn die Eigenschaft nicht explizit angegeben ist, findet keine Verhaltensänderung statt. Wenn Sie eine Verbindung zu einem HTTP-Server herstellen, der SPNEGO zum Aushandeln der Authentifizierung nutzt, und wenn die Anmeldung und Authentifizierung beim Server erfolgreich sind, werden die Authentifizierungsinformationen gecacht und für weitere Verbindungen zum gleichen Server erneut verwendet. Beim Herstellen einer Verbindung zu einem HTTP SPNEGO-Server wird außerdem in der Regel die zugrundeliegende Verbindung aufrechterhalten und für weitere Anforderungen an den gleichen Server wiederverwendet. In einigen Anwendungen kann es sinnvoll sein, das gesamte Caching für das HTTP SPNEGO (Negotiate/Kerberos)-Protokoll zu deaktivieren, um für jede neue Anforderung an den Server eine neue Authentifizierung zu erzwingen.

Diese Änderung beinhaltet eine neue Systemeigenschaft, mit der Sie die Caching-Policy für HTTP SPNEGO-Verbindungen steuern können. Wenn jdk.spnego.cache definiert ist und die Auswertung "false" ergibt, wird das gesamte Caching für HTTP SPNEGO-Verbindungen deaktiviert. Das Festlegen der Systemeigenschaft auf "false" führt jedoch zu unerwünschten Auswirkungen:
- Die Performance von HTTP SPNEGO-Verbindungen wird hierdurch möglicherweise erheblich beeinträchtigt, da die Verbindung bei jeder neuen Anforderung erneut authentifiziert werden muss, was einen mehrfachen Kommunikationsaustausch mit dem Server erfordert.
- Da die Zugangsdaten für jede neue Anforderung erneut abgerufen werden müssen, wird möglicherweise ein Popup-Fenster angezeigt, in dem Benutzer bei jeder neuen Anforderung zur Eingabe ihrer Zugangsdaten aufgefordert werden. Dies hängt von der globalen Implementierung des Authentikators sowie davon ab, ob die transparente Authentifizierung verfügbar ist.
JDK-8170814 (nicht allgemein zugänglich)
Neue Systemeigenschaft zum Steuern des Cachings für HTTP NTLM-Verbindung.
Es wird eine neue Systemeigenschaft zum Steuern des Cachings für HTTP NTLM-Verbindungen eingeführt. Diese Systemeigenschaft ist spezifisch für JDK-Implementierungen. Das Caching für HTTP NTLM-Verbindungen bleibt standardmäßig aktiviert. Dementsprechend findet keine Verhaltensänderung statt, wenn die Eigenschaft nicht explizit angegeben ist. Auf einigen Plattformen unterstützt die HTTP NTLM-Implementierung im JDK die transparente Authentifizierung, wenn die Zugangsdaten eines Systembenutzers auf Systemebene verwendet werden. Wenn die transparente Authentifizierung nicht verfügbar oder nicht erfolgreich ist, unterstützt das JDK nur das Abrufen der Zugangsdaten von einem globalen Authentikator. Wenn die Verbindung zum Server erfolgreich ist, werden die Authentifizierungsinformationen gecacht und für weitere Verbindungen zum gleichen Server wiederverwendet. Beim Herstellen einer Verbindung zu einem HTTP NTLM-Server wird außerdem in der Regel die zugrundeliegende Verbindung aufrechterhalten und für weitere Anforderungen an den gleichen Server wiederverwendet. In einigen Anwendungen kann es sinnvoll sein, das gesamte Caching für das HTTP NTLM-Protokoll zu deaktivieren, um für jede neue Anforderung an den Server eine neue Authentifizierung zu erzwingen.

Diese Änderung beinhaltet eine neue Systemeigenschaft, mit der Sie die Caching-Policy für HTTP NTLM-Verbindungen steuern können. Wenn jdk.ntlm.cache definiert ist und die Auswertung "false" ergibt, wird das gesamte Caching für HTTP NTLM-Verbindungen deaktiviert. Das Festlegen der Systemeigenschaft auf "false" führt jedoch zu unerwünschten Auswirkungen:
- Die Performance von HTTP NTLM-Verbindungen wird hierdurch möglicherweise erheblich beeinträchtigt, da die Verbindung bei jeder neuen Anforderung erneut authentifiziert werden muss, was einen mehrfachen Kommunikationsaustausch mit dem Server erfordert.
- Da die Zugangsdaten für jede neue Anforderung erneut abgerufen werden müssen, wird möglicherweise ein Popup-Fenster angezeigt, in dem Benutzer bei jeder neuen Anforderung zur Eingabe ihrer Zugangsdaten aufgefordert werden. Dies hängt von der globalen Implementierung des Authentikators sowie davon ab, ob die transparente Authentifizierung verfügbar ist.
JDK-8163520 (nicht allgemein zugänglich)
Neue Version von VisualVM
VisualVM 1.3.9 wurde am 4. Oktober 2016 freigegeben http://visualvm.github.io/relnotes.html und mit 8u131 integriert. Siehe JDK-8167485

Java-Ablaufdatum

Das Ablaufdatum für 8u131 ist der 18. Juli 2017. Java wird ungültig, sobald ein neues Release mit verbesserter Sicherheit verfügbar wird. Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u131) auf Basis eines alternativen Mechanismus am 18. August 2017 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von Java durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren.

Bugfixes

Dieses Release enthält Korrekturen zum Schließen von Sicherheitslücken. Weitere Informationen finden Sie in Oracle Java SE Critical Patch Update Advisory. Eine Liste der in diesem Release enthaltenen Bugfixes finden Sie auf der Seite JDK 8u131 Bugfixes.

» 8u131-Versionshinweise

Java 8 Update 121 (8u121)

Releasehauptmerkmale

IANA Data 2016i
JDK 8u121 enthält Version 2016i der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.
Bugfix: Trackpad-Scrolling von Text unter OS X 10.12 Sierra ist sehr schnell
Die MouseWheelEvent.getWheelRotation()-Methode hat unter Mac OS X gerundete native NSEvent-DeltaX/Y-Ereignisse wiedergegeben. Das neueste macOS Sierra 10.12 erzeugt sehr kleine NSEvent-DeltaX/Y-Werte, sodass das Runden und Aufaddieren der Werte zu dem großen von MouseWheelEvent.getWheelRotation() wiedergegebenen Wert führt. Der JDK-8166591-Fix sammelt NSEvent-DeltaX/Y-Werte an, und die MouseWheelEvent.getWheelRotation()-Methode gibt nur dann Werte ungleich Null zurück, wenn der angesammelte Wert einen Schwellen- und Nullwert übersteigt. Dies ist kompatibel zur MouseWheelEvent.getWheelRotation()-Spezifikation: "Gibt die Anzahl an "Klicks" als Ganzzahl wieder, um die das Mausrad gedreht wurde. Eine teilweise Drehung kann erfolgen, wenn die Maus ein Rad mit hoher Auflösung unterstützt. In diesem Fall gibt die Methode Null zurück, bis sich ein vollständiger "Klick" angesammelt hat." Um die genaue Anzahl an Raddrehungen zu ermitteln, verwenden Sie stattdessen die Methode MouseWheelEvent.getPreciseWheelRotation(). Siehe JDK-8166591
Standard-EC-Stärke in JDK verbessern
Um die Standardstärke der EC-Kryptografie zu verbessern, wurden EC-Schlüssel mit weniger als 224 Bits in der Zertifizierungspfadverarbeitung (über die Sicherheitseigenschaft jdk.certpath.disabledAlgorithms) und SSL/TLS-Verbindungen (über die Sicherheitseigenschaft jdk.tls.disabledAlgorithms) in JDK deaktiviert. Anwendungen können diese Einschränkung in den Sicherheitseigenschaften aktualisieren und kleinere Schlüsselgrößen zulassen, wenn dies wirklich erforderlich ist (Beispiel: "EC keySize < 192"). EC-Kurven mit weniger als 256 Bits werden von der SSL/TLS-Implementierung in JDK entfernt. Die neue Systemeigenschaft jdk.tls.namedGroups definiert eine Liste der aktivierten benannten Kurven für EC-Cipher Suites in der Reihenfolge ihrer Priorität. Wenn die standardmäßig aktivierten EC-Kurven oder die Kurvenvoreinstellungen für eine Anwendung angepasst werden müssen, aktualisieren Sie die Systemeigenschaft entsprechend. Beispiel:
```
 jdk.tls.namedGroups="secp256r1, secp384r1, secp521r1" 
```
Beachten Sie, dass die standardmäßig aktivierten oder angepassten EC-Kurven die Algorithmus-Constraints einhalten. Beispiel: Die deaktivierten EC-Schlüssel, die in den Java-Sicherheitseigenschaften definiert sind, können nicht von den angepassten EC-Kurven erneut aktiviert werden. Siehe JDK-8148516
Neu: Option "--allow-script-in-comments" für Javadoc
Das Javadoc-Tool akzeptiert Vorkommen von JavaScript-Code in den Javadoc-Dokumentationskommentaren und Befehlszeilenoptionen jetzt nur, wenn die Befehlszeilenoption --allow-script-in-comments angegeben ist. Mit der Option --allow-script-in-comments wird JavaScript-Code in Dokumentationskommentaren und Befehlszeilenoptionen vom Javadoc-Tool beibehalten. Ein Fehler wird im Javadoc-Tool ausgegeben, wenn JavaScript-Code vorkommt, aber die Befehlszeilenoption nicht festgelegt ist.
JDK-8138725 (nicht allgemein zugänglich)
Mindestschlüssellänge für XML-Signaturen auf 1024 erhöhen
Der sichere Validierungsmodus für die Implementierung von XML-Signaturen wurde dahingehend verbessert, dass RSA- und DSA-Schlüssel mit weniger als 1024 Bit standardmäßig eingeschränkt werden, da sie für digitale Signaturen nicht mehr sicher genug sind. Darüber hinaus wurde eine neue Sicherheitseigenschaft namens jdk.xml.dsig.SecureValidationPolicy zur java.security-Datei hinzugefügt. Sie kann verwendet werden, um die Durchsetzung der unterschiedlichen Einschränkungen zu kontrollieren, wenn der sichere Validierungsmodus aktiviert wird. Der sichere Validierungsmodus wird aktiviert, indem Sie entweder die XML-Signatureigenschaft org.jcp.xml.dsig.secureValidation mit der javax.xml.crypto.XMLCryptoContext.setProperty-Methode auf "true" setzen oder den Code mit einem SecurityManager ausführen. Wenn eine XML-Signatur mit einem schwachen RSA- oder DSA-Schlüssel generiert oder validiert wird, wird eine XMLSignatureException ausgelöst, und es wird folgende Meldung angezeigt: "RSA keys less than 1024 bits are forbidden when secure validation is enabled" (RSA-Schlüssel mit weniger als 1024 Bit sind nicht zulässig, wenn die sichere Validierung aktiviert ist) bzw. "DSA keys less than 1024 bits are forbidden when secure validation is enabled" (DSA-Schlüssel mit weniger als 1024 Bit sind nicht zulässig, wenn die sichere Validierung aktiviert ist).
JDK-8140353 (nicht allgemein zugänglich)
Zertifikate mit DS-Schlüsseln mit weniger als 1024 Bit einschränken
DSA-Schlüssel mit weniger als 1024 Bit sind nicht sicher genug und müssen beim Erstellen und Validieren des Zertifizierungspfades eingeschränkt werden. Deshalb wurden DSA-Schlüssel mit weniger als 1024 Bit durch Hinzufügen von "DSA keySize < 1024" zur Sicherheitseigenschaft "jdk.certpath.disabledAlgorithms" standardmäßig deaktiviert. Anwendungen können diese Einschränkung in der Sicherheitseigenschaft ("jdk.certpath.disabledAlgorithms") aufheben und kleinere Schlüsselgrößen zulassen, wenn dies wirklich erforderlich ist (Beispiel: "DSA keySize < 768"). JDK-8139565 (nicht allgemein zugänglich)
Weitere Prüfungen zum DER-Verschlüsselungsparsingcode hinzugefügt
Zum DER-Verschlüsselungsparsingcode wurden weitere Prüfungen hinzugefügt, um verschiedene Verschlüsselungsfehler abzufangen. Darüber hinaus führen Signaturen, die eine erstellte Codierung mit unbegrenzter Länge enthalten, nun zu einer IOException beim Parsen. Beachten Sie, dass mit JDK-Standardprovidern erzeugte Signaturen von dieser Änderung nicht betroffen sind. JDK-8168714 (nicht allgemein zugänglich)
Zusätzliche Zugriffsbeschränkungen für URLClassLoader.newInstance
Mit den java.net.URLClassLoader.newInstance-Methoden erstellte Class Loaders können zum Laden von Klassen aus einer Liste angegebener URLs verwendet werden. Wenn der aufrufende Code keinen Zugriff auf mindestens eine URL hat und die URL-Artefakte, auf die zugegriffen werden kann, nicht die erforderliche Klasse enthalten, wird die Methode ClassNotFoundException oder Ähnliches ausgelöst. Früher wurde eine SecurityException ausgelöst, wenn der Zugriff auf eine URL verweigert wurde. Wenn das alte Verhalten wiederhergestellt werden muss, kann diese Änderung durch Festlegen der Systemeigenschaft jdk.net.URLClassPath.disableRestrictedPermissions deaktiviert werden. JDK-8151934 (nicht allgemein zugänglich)
Neue konfigurierbare Eigenschaft in logging.properties java.util.logging.FileHandler.maxLocks
Eine neue konfigurierbare Eigenschaft "java.util.logging.FileHandler.maxLocks" wurde zum java.util.logging.FileHandler hinzugefügt. Diese neue Logging-Eigenschaft kann in der Logging-Konfigurationsdatei definiert werden und ermöglicht die Konfiguration der maximalen Anzahl an gleichzeitigen Logdateisperren, die ein FileHandler bearbeiten kann. Der Standardwert ist 8080. In einer hochgradig nebenläufigen Umgebung, in der viele (mehr als 101) Standalone-Clientanwendungen die JDK-Logging-API mit FileHandler gleichzeitig verwenden, kann es vorkommen, dass der Standardgrenzwert von 100 erreicht wird, was dazu führt, dass keine FileHandler-Dateisperren mehr angefordert werden können und eine IO-Exception ausgelöst wird. In einem solchen Fall können Sie mit der neuen Logging-Eigenschaft die maximale Anzahl an Sperren erhöhen, bevor Sie die Anwendung bereitstellen. Der Standardwert von maxLocks (100) bleibt unverändert, falls dieser nicht überschrieben wird. Weitere Einzelheiten finden Sie in der Dokumentation zur java.util.logging.LogManager- und java.util.logging.FileHandler-API. Siehe JDK-8153955

Hinweise

Verbesserter Schutz für das Laden von JNDI-Remoteklassen

Das Laden von Remoteklassen über JNDI-Objekt-Factorys, die im Naming Service und Directory Service gespeichert sind, ist standardmäßig deaktiviert. Um das Laden von Remoteklassen durch RMI-Registry oder COS-Naming Service-Provider zu aktivieren, setzen Sie die folgende Systemeigenschaft auf den Wert "true":


 com.sun.jndi.rmi.object.trustURLCodebase com.sun.jndi.cosnaming.object.trustURLCodebase

JDK-8158997 (nicht allgemein zugänglich)

Mit "jarsigner -verbose -verify" werden die Algorithmen gedruckt, die zum Signieren der JAR-Datei verwendet werden

Das jarsigner-Tool wurde verbessert und zeigt nun auch die Details der Algorithmen und Schlüssel an, die zur Erzeugung einer signierten JAR-Datei verwendet werden. Zudem wird angegeben, ob einige der Algorithmen und Schlüssel als schwach angesehen werden.

Beim Aufruf von "jarsigner -verify -verbose filename.jar" wird ein separater Abschnitt ausgegeben, der Informationen zur Signatur und zum Zeitstempel (sofern vorhanden) in der signierten JAR-Datei anzeigt, auch wenn diese aus verschiedenen Gründen als nicht signiert behandelt wird. Wenn ein Algorithmus oder Schlüssel gemäß den Spezifikationen in der Sicherheitseigenschaft jdk.jar.disabledAlgorithmsals schwach angesehen wird, wird er mit "(weak)" gekennzeichnet.

Beispiel:


 - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key

Siehe JDK-8163304

Bekannte Probleme

javapackager und fx:deploy bündeln das gesamte JDK statt JRE

Im Java Packager für Mac liegt ein bekannter Bug vor. Unter Umständen wird dort das gesamte JDK mit dem Anwendungs-Bundle gebündelt, was zu einem ungewöhnlich großen Bundle führt. Der Workaround besteht darin, die Bundler-Option -Bruntime zu verwenden. Beispiel: -Bruntime=JavaAppletPlugin.plugin, wobei sich das JavaAppletPlugin.plugin für die zu bündelnde JRE im aktuellen Verzeichnis befindet. Siehe JDK-8166835

Die Installation von Java ist für Nicht-Admin-Benutzer mit deaktivierter Steuerung des Benutzerzugriffs nicht erfolgreich

Die Installation von Java unter Windows ist für Nicht-Admin-Benutzer, bei denen die Steuerung des Benutzerzugriffs (User Access Control, UAC) deaktiviert ist, nicht erfolgreich, und es wird keine Warnung oder Eingabeaufforderung angezeigt. Das Installationsprogramm hinterlässt ein Verzeichnis (jds<number>.tmp) im Verzeichnis %TEMP%.
JDK-8161460 (nicht allgemein zugänglich)

Neue Features

Zusätzliche Sicherheitseigenschaft zur Konfiguration des sicheren XML-Signaturüberprüfungsmodus

Eine neue Sicherheitseigenschaft mit dem Namen jdk.xml.dsig.secureValidationPolicy wurde hinzugefügt. Mit ihr können Sie die individuellen Einschränkungen konfigurieren, die durchgesetzt werden, wenn der sichere Überprüfungsmodus der XML-Signatur aktiviert ist. Der Standardwert für diese Eigenschaft in der java.security-Konfigurationsdatei lautet:


 jdk.xml.dsig.secureValidationPolicy=\ disallowAlg http://www.w3.org/TR/1999/REC-xslt-19991116,\ disallowAlg http://www.w3.org/2001/04/xmldsig-more#rsa-md5,\ disallowAlg http://www.w3.org/2001/04/xmldsig-more#hmac-md5,\ disallowAlg http://www.w3.org/2001/04/xmldsig-more#md5,\ maxTransforms 5,\ maxReferences 30,\ disallowReferenceUriSchemes file http https,\ noDuplicateIds,\ noRetrievalMethodLoops

Weitere Informationen finden Sie in der Definition der Eigenschaft in der java.security-Datei. Siehe JDK-8151893

Serialisierungsfilterkonfiguration

Mit der Serialisierungsfilterung wird ein neues Verfahren eingeführt, mit dem eingehende Streams von Objektserialisierungsdaten zur Verbesserung von Sicherheit und Stabilität gefiltert werden können. Bei der Deserialisierung wendet jeder ObjectInputStream einen Filter (sofern konfiguriert) auf den Streaminhalt an. Filter werden entweder als eine Systemeigenschaft oder als eine Sicherheitseigenschaft konfiguriert. Die "jdk.serialFilter"-Muster sind in JEP 290 Serialization Filtering und in <JRE>/lib/security/java.securitybeschrieben. Filteraktionen werden im Logger "java.io.serialization" protokolliert (sofern aktiviert). Siehe JDK-8155760

Bessere RMI-Constraint-Prüfung

RMI-Registry und verteilte Garbage Collection verwenden die Verfahren der JEP 290 Serialisierungsfilterung, um die Servicestabilität zu verbessern. RMI-Registry und verteilte Garbage Collection implementieren integrierte Filter der weißen Liste für die typischen Klassen, deren Verwendung bei den einzelnen Services erwartet wird. Zusätzliche Filtermuster können entweder als eine Systemeigenschaft oder als eine Sicherheitseigenschaft konfiguriert werden. Die Syntax des "sun.rmi.registry.registryFilter"- und "sun.rmi.transport.dgcFilter"-Eigenschaftsmusters ist in JEP 290 und in <JRE>/lib/security/java.security beschrieben. JDK-8156802 (nicht allgemein zugänglich)

Verfahren hinzufügen, damit Nicht-Standard-Root-CAs keinen Algorithmuseinschränkungen unterliegen

In der java.security-Datei wird ein zusätzlicher Constraint namens "jdkCA" zur jdk.certpath.disabledAlgorithms-Eigenschaft hinzugefügt. Dieser Constraint lässt den angegebenen Algorithmus nicht zu, wenn der Algorithmus in einer Zertifikatskette verwendet wird, die an einem markierten Vertrauensanker im lib/security/cacerts-Keystore endet. Wenn der jdkCA-Constraint nicht festgelegt wurde, werden alle Ketten mit dem angegebenen Algorithmus eingeschränkt. jdkCA darf nur einmal in einem DisabledAlgorithm-Ausdruck verwendet werden. Beispiel: Schließen Sie zum Anwenden dieses Constraints auf SHA-1-Zertifikate Folgendes ein: SHA1 jdkCA
Siehe JDK-8140422

Java-Ablaufdatum

Ablaufdatum für 8u121 ist der 18. April 2017. Java wird ungültig, sobald ein neues Release mit verbesserter Sicherheit verfügbar wird. Bei Systemen, die nicht auf Oracle Server zugreifen können, läuft diese JRE (Version 8u121) auf Basis eines alternativen Verfahrens am 18. Mai 2017 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von Java durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren.

Bugfixes

» 8u121-Versionshinweise

Java 8 Update 111 (8u111)

Releasehauptmerkmale

IANA Data 2016f
JDK 8u101 enthält Version 2016f der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software. Siehe JDK-8159684.
Zertifikatänderungen: Neue JCE-Codesignatur-Root-CA
Damit längere Schlüssellängen und stärkere Signaturalgorithmen unterstützt werden können, wurde eine neue Codesignatur-Root Certificate Authority für JCE-Provider erstellt. Deren Zertifikat wurde zu Oracle JDK hinzugefügt. Neue Codesignaturzertifikate für JCE-Provider, die von dieser CA ausgegeben werden, werden ab sofort zur Signatur von JCE-Providern verwendet. Standardmäßig werden neue Anforderungen für Codesignaturzertifikate des JCE-Providers von dieser CA ausgestellt.

Vorhandene Zertifikate von der aktuellen Codesignatur-Root des JCE-Providers werden weiterhin validiert. Diese Root-CA kann jedoch zu einem späteren Zeitpunkt deaktiviert werden. Es wird empfohlen, dass neue Zertifikate angefordert und vorhandene Provider-JARs neu signiert werden. Weitere Einzelheiten zu dem Signaturprozess des JCE-Providers finden Sie in der Dokumentation How to Implement a Provider in the Java Cryptography Architecture. JDK-8141340 (nicht allgemein zugänglich)
Services des Service-Menüs
Die Lebenszyklusverwaltung von AWT-Menükomponenten hat auf bestimmten Plattformen zu Problemen geführt. Dieser Fix verbessert die Statussynchronisierung zwischen Menüs und deren Containern. JDK-8158993 (nicht allgemein zugänglich)
Basisauthentifizierung für HTTPS-Tunneling deaktivieren
In einigen Umgebungen sind bestimmte Authentifizierungsschemas beim Proxying von HTTPs möglicherweise nicht erwünscht. Demzufolge wurde das Basisauthentifizierungsschema standardmäßig in Oracle Java Runtime deaktiviert, indem "Basic" zu der Networkingeigenschaft jdk.http.auth.tunneling.disabledSchemes hinzugefügt wurde. Jetzt werden Proxys, die die Basisauthentifizierung erfordern, wenn ein Tunnel für HTTPS eingerichtet wird, nicht mehr standardmäßig erfolgreich ausgeführt. Falls erforderlich kann dieses Authentifizierungsschema reaktiviert werden, indem Basic aus der Networkingeigenschaft jdk.http.auth.tunneling.disabledSchemes entfernt wird, oder indem eine Systemeigenschaft mit demselben Namen in der Befehlszeile auf "" ( leer ) gesetzt wird. Darüber hinaus können die Networkingeigenschaften jdk.http.auth.tunneling.disabledSchemes und jdk.http.auth.proxying.disabledSchemes sowie die Systemeigenschaften mit demselben Namen verwendet werden, um andere Authentifizierungsschemas zu deaktivieren, die möglicherweise aktiv sind, wenn Tunneling für HTTPS eingerichtet wird oder wenn Proxying für einfaches HTTP verwendet wird. JDK-8160838 (nicht allgemein zugänglich)
JARs begrenzen, die mit schwachen Algorithmen und Schlüsseln signiert sind
Dieses JDK-Release führt neue Einschränkungen für die Prüfung von signierten JAR-Dateien ein. Wenn die signierte JAR-Datei einen deaktivierten Algorithmus oder eine Schlüsselgröße verwendet, die kleiner ist als die Mindestlänge, ignorieren Vorgänge der Signaturverifizierung die Signatur und behandeln die JAR-Datei so als wäre sie unsigniert. Dies kann potenziell bei den folgenden Anwendungstypen auftreten, die signierte JAR-Dateien verwenden:
1. Applets oder Web Start-Anwendungen
2. Standalone- oder Serveranwendungen, die mit einem aktivierten SecurityManager ausgeführt werden und mit einer Richtliniendatei konfiguriert sind, die Berechtigungen gemäß den Codesignaturgebern der JAR-Datei erteilt.

Die Liste der deaktivierten Algorithmen wird über eine neue Sicherheitseigenschaft, jdk.jar.disabledAlgorithms, in der Datei java.security kontrolliert. Diese Eigenschaft enthält eine Liste mit deaktivierten Algorithmen und Schlüsselgrößen für kryptografisch signierte JAR-Dateien.

Die folgenden Algorithmen und Schlüsselgrößen sind in diesem Release eingeschränkt:
1. MD2 (entweder im Digest- oder Signaturalgorithmus)
2. RSA-Schlüssel mit weniger als 1024 Bit
HINWEIS: Es ist geplant, MD5-basierte Signaturen in signierten JARs in der CPU von April 2017 einzuschränken.

Mit der jarsigner-Binärdatei, die mit diesem JDK geliefert wird, kann geprüft werden, ob ein schwacher Algorithmus oder Schlüssel für die Signatur einer JAR-Datei verwendet wurde. Wenn jarsigner -verify -J-Djava.security.debug=jar für eine JAR-Datei ausgeführt wird, die mit einem schwachen Algorithmus oder Schlüssel signiert wurde, werden weitere Informationen zu dem deaktivierten Algorithmus oder Schlüssel ausgegeben.

Beispiel: Um eine JAR-Datei namens test.jar zu prüfen, verwenden Sie den folgenden Befehl:
jarsigner -verify -J-Djava.security.debug=jar test.jar

Wenn die Datei in diesem Beispiel mit einem schwachen Signaturalgorithmus wie MD2withRSA signiert wurde, würde Folgendes ausgegeben:
jar: beginEntry META-INF/my_sig.RSA
jar: processEntry: processing block
jar: processEntry caught: java.security.SignatureException: Signature check failed. Disabled algorithm used: MD2withRSA
jar: done with meta!

Der aktualisierte jarsigner-Befehl wird mit folgender Warnung in der Standardausgabe beendet:
"Signatur kann nicht geparst oder geprüft werden. Die JAR-Datei wird als nicht signiert behandelt. Die JAR-Datei wurde möglicherweise mit einem schwachen Algorithmus signiert, der jetzt deaktiviert ist. Um weitere Informationen zu erhalten, führen Sie jarsigner mit aktiviertem Debug erneut aus (-J-Djava.security.debug=jar)"

Um das Problem zu lösen, muss die JAR-Datei erneut mit einem stärkeren Algorithmus oder einer größeren Schlüsselgröße signiert werden. Alternativ können die Einschränkungen rückgängig gemacht werden, indem die anwendbaren schwachen Algorithmen oder Schlüsselgrößen aus jdk.jar.disabledAlgorithms entfernt werden; diese Option wird jedoch nicht empfohlen. Bevor Sie die betroffenen JAR-Dateien erneut signieren, müssen die vorhandenen Signaturen aus der JAR-Datei entfernt werden. Hierzu kann das zip-Utility wie folgt verwendet werden:

zip -d test.jar 'META-INF/*.SF' 'META-INF/*.RSA' 'META-INF/*.DSA'

Prüfen Sie die Oracle JRE and JDK Cryptographic Roadmap unter http://java.com/cryptoroadmap regelmäßig auf geplante Einschränkungen für signierte JAR-Dateien und andere Sicherheitskomponenten. Beachten Sie insbesondere die Absicht, MD5-basierte Signaturen in signierten JAR-Dateien in der CPU von April 2017 einzuschränken.

Um zu testen, ob die JARs mit MD5 signiert wurden, fügen Sie MD5 zur jdk.jar.disabledAlgorithms-Sicherheitseigenschaft hinzu. Beispiel:

jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024

. Führen Sie danach jarsigner -verify -J-Djava.security.debug=jar für die JAR-Dateien aus, wie oben beschrieben.
JDK-8155973 (nicht allgemein zugänglich)
Warnmeldung zu dem Deployment-Authentikator-Dialogfeld hinzugefügt
Eine Warnmeldung wurde zu dem Dialogfeld zur Plug-in-Authentifizierung in den Fällen hinzugefügt, in denen die HTTP-Basisauthentifizierung (Zugangsdaten werden unverschlüsselt gesendet) verwendet wird, während ein Proxy verwendet wird bzw. während keine SSL/TLS-Protokolle verwendet werden
"WARNING: Basic authentication scheme will effectively transmit your credentials in clear text. Do you really want to do this?" ( Warnung: Das Basisauthentifizierungsschema überträgt Ihre Zugangsdaten als Klartext. Möchten Sie dies wirklich?)
JDK-8161647 (nicht allgemein zugänglich)

Bekannte Probleme

Einige Ereignisse sind in JFR-Aufzeichnungen in Windows nicht verfügbar

Die folgenden Ereignisse sind in den JFR-Aufzeichnungen in Windows für Release 8u111 nicht verfügbar:

hotspot/jvm/os/processor/cpu_load
os/processor/context_switch_rate

Dies ist auf Regressions-JDK-8063089 zurückzuführen, das in 8u111 mit den Änderungen für JDK-8162419 eingeführt wurde. Der Fix für JDK-8063089 konnte in dem 8u111-Release nicht einbezogen werden. Er wird in dem nächsten 8u111-BPR-Build und in dem nächsten allgemein zugänglichen Release enthalten sein.
JDK-8063089 (nicht allgemein zugänglich)

JVM löst NullPointerExceptions bei macOS Sierra 10.12 aus

Wenn ein Benutzer bei macOS Sierra 10.12 Zusatztasten drückt (wie Befehlstaste, Umschalttaste oder Alt), während ein Applet in einem Browser ausgeführt wird, wird möglicherweise ein Fehlerfeld mit der Bezeichnung "Interner Fehler" angezeigt. Außerdem wird das "exec"-Symbol im macOS-Dock angezeigt. Der Benutzer kann das Applet schließen oder kann versuchen, das Applet erneut auszuführen, ohne dabei eine Zusatztaste zu drücken. Siehe JDK-8165867.

Java-Ablaufdatum

Das Ablaufdatum für 8u111 ist der 17. Januar 2017. Java wird ungültig, sobald ein neues Release mit verbesserter Sicherheit verfügbar wird. Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u111) auf Basis eines alternativen Mechanismus am 17. Februar 2017 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von Java durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren.

Bugfixes

» 8u111-Versionshinweise

Java 8 Update 101 (8u101)

Releasehauptmerkmale

IANA Data 2016d
JDK 8u101 enthält Version 2016d der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software. Siehe JDK-8151876.
Zertifikatänderungen
Neue DTrust-Zertifikate zu Root-CAs hinzugefügt
Zwei neue Root-Zertifikate wurden hinzugefügt:
- D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE
- D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE
Siehe JDK-8153080

Neue Iden-Zertifikate zu Root-CAs hinzugefügt
Drei neue Root-Zertifikate wurden hinzugefügt:
- IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US
- IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US
- IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co.
Siehe JDK-8154757

Comodo Root-CA entfernt
Das Comodo "UTN - DATACorp SGC" Root-CA-Zertifikat wurde aus der cacerts-Datei entfernt. Siehe JDK-8141540

Sonera Class1 CA entfernt
Das "Sonera Class1 CA" Root-CA-Zertifikat wurde aus der cacerts-Datei entfernt. Siehe JDK-8141276.
Zugriffskontrolle für javax.rmi.CORBA.ValueHandler verbessern
Die javax.rmi.CORBA.Util-Klasse stellt Methoden bereit, die von Stubs und Ties zur Ausführung allgemeiner Vorgänge verwendet werden können. Sie kann auch als Factory für ValueHandlers verwendet werden. Die javax.rmi.CORBA.ValueHandler-Schnittstelle stellt Services bereit, die das Lesen und Schreiben von Werttypen in GIOP-Streams unterstützen. Das Sicherheitsbewusstsein dieser Utilitys wurde durch die Einführung einer Berechtigung java.io.SerializablePermission("enableCustomValueHanlder") erweitert. Sie wird verwendet, um eine vertrauenswürdige Beziehung zwischen den Benutzern von javax.rmi.CORBA.Util- und javax.rmi.CORBA.ValueHandler-APIs herzustellen.

Die erforderliche Berechtigung ist "enableCustomValueHanlder" SerializablePermission. Drittanbieter-Code, der mit einem installierten SecurityManager ausgeführt wird, jedoch die neue Berechtigung beim Aufruf von Util.createValueHandler() nicht hat, löst eine AccessControlException aus und wird nicht erfolgreich ausgeführt.

Dieses Berechtigungsprüfungsbehavior kann in JDK8u und früheren Releases außer Kraft gesetzt werden, indem eine Systemeigenschaft, "jdk.rmi.CORBA.allowCustomValueHandler" definiert wird.

Für externe Anwendungen, die javax.rmi.CORBA.Util.createValueHandler explizit aufrufen, ist eine Konfigurationsänderung erforderlich, damit sie funktionieren, wenn ein SecurityManager installiert und keine der folgenden beiden Anforderungen erfüllt ist:
1. java.io.SerializablePermission("enableCustomValueHanlder") wird nicht von SecurityManager erteilt.
2. Bei Anwendungen, die mit JDK8u und früher ausgeführt werden, ist die Systemeigenschaft "jdk.rmi.CORBA.allowCustomValueHandler" entweder nicht definiert oder als "False" (ohne Beachtung der Groß-/Kleinschreibung) definiert.
Beachten Sie, dass der Tippfehler "enableCustomValueHanlder" in den Oktober 2016-Releases korrigiert wird. In diesen und zukünftigen JDK-Releases ist "enableCustomValueHandler" die korrekte SerializationPermission.
JDK-8079718 (nicht allgemein zugänglich)
jarsigner unterstützt jetzt die Angabe des Zeitstempel-Hashalgorithmus
Eine neue Option -tsadigestalg wurde zu jarsigner hinzugefügt. Mit dieser Option wird der Message-Digest-Algorithmus angegeben, mit dem der Nachrichten-Imprint generiert wird, der an den TSA-Server gesendet werden muss. In älteren JDK-Releases wurde SHA-1 als Message-Digest-Algorithmus verwendet. Wenn diese neue Option nicht angegeben wird, wird SHA-256 bei JDK 7 Updates und späteren Versionen der JDK-Familie verwendet. Bei JDK 6 Updates bleibt SHA-1 der Standard, es wird jedoch eine Warnung an den Standardausgabestream ausgegeben. Siehe JDK-8038837.
MSCAPI KeyStore kann gleichnamige Zertifikate verarbeiten
Java SE KeyStore lässt keine Zertifikate zu, die dieselben Aliasnamen haben. Bei Windows dürfen jedoch mehrere Zertifikate, die in einem Keystore gespeichert sind, nicht eindeutige benutzerfreundliche Namen haben. Durch den Fix für JDK-6483657 können derartige, nicht eindeutig benannte Zertifikate über die Java-API verwendet werden, indem die sichtbaren Aliasnamen künstlich eindeutig gemacht werden. Beachten Sie, dass mit diesem Fix keine gleichnamigen Zertifikate mit der Java-API erstellt werden können. Mit ihm können Sie nur gleichnamige Zertifikate verwenden, die von Fremdherstellertools zu dem Keystore hinzugefügt wurden. Es wird dennoch empfohlen, dass Sie bei Ihrem Design nicht mehrere Zertifikate mit demselben Namen verwenden. Insbesondere der folgende Satz wird nicht aus der Java-Dokumentation gestrichen:
"In order to avoid problems, it is recommended not to use aliases in a KeyStore that only differ in case." (Um Probleme zu vermeiden, wird empfohlen, dass keine Aliasnamen in einem Keystore verwendet werden, die sich auch nur in der Schreibweise unterscheiden.)
Siehe JDK-6483657.
Deployment-Toolkit-API-Methoden installieren JRE nicht mehr
Die Deployment-Toolkit-API-Methoden installLatestJRE() und installJRE(requestedVersion) aus deployJava.js und die install()-Methode aus dtjava.js installieren das JRE nicht mehr. Wenn die Java-Version eines Benutzers unter der Sicherheits-Baseline liegt, wird der Benutzer zu java.com umgeleitet, damit er ein aktualisiertes JRE herunterladen kann. JDK-8148310 (nicht allgemein zugänglich)
DomainCombiner prüft die Laufzeit-Policy nicht mehr auf statische ProtectionDomain-Objekte, wenn ProtectionDomain-Objekte kombiniert werden
Anwendungen, die statische ProtectionDomain-Objekte (die mit dem 2-Arg-Konstruktor erstellt werden) mit einem nicht ausreichenden Set von Berechtigungen verwenden, können jetzt bei dieser Korrektur eine AccessControlException erhalten. Sie müssen entweder die statischen ProtectionDomain-Objekte durch dynamische Objekte (mit dem 4-Arg-Konstruktur) ersetzen, deren Berechtigungsset durch die aktuelle Policy erweitert wird, oder müssen das statische ProtectionDomain-Objekt mit allen erforderlichen Berechtigungen erstellen. JDK-8147771 (nicht allgemein zugänglich)

Bekannte Probleme

JRE 8u101 wird von Internet Explorer (IE) nicht erkannt, wenn statische Klassen-ID verwendet wird

Wenn eine statische Klassen-ID zum Starten eines Applets oder einer Webstart-Anwendung während der Benutzung von JRE 8u101 verwendet wird, wird Benutzern ein unerwünschtes Dialogfeld angezeigt, in dem angegeben wird, dass sie entweder die neueste JRE verwenden oder den Startvorgang abbrechen sollen, obwohl sie die neueste JRE (JRE 8u101) installiert haben und verwenden. Dieser spezifische Fall tritt nur bei Windows und IE auf.

Es wird davon abgeraten, eine statische Klassen-ID für die Auswahl der JRE-Version zu verwenden (seit JDK 5u6, Dezember 2005) gemäß http://www.oracle.com/technetwork/java/javase/family-clsid-140615.html.

Benutzer haben zwei Möglichkeiten, dieses Problem zu umgehen:

Mit der neuesten Version (8u101) starten und die Warnung ignorieren.
Installieren von JRE 8u102 anstelle von JRE 8u101, um dieses Problem zu vermeiden.

Entwickler haben zwei Möglichkeiten, dieses Problem zu lösen:

Verwenden einer dynamischen Klassen-ID anstelle der statischen Klassen-ID.
Verwenden von java_version bei der Benutzung eines HTML-Applets oder Verwenden eines JNLP-Deskriptors bei der Benutzung von JNLP.

JDK-8147457 (nicht allgemein zugänglich)

Bugfixes

Java-Ablaufdatum

Das Ablaufdatum für 8u101 ist der 19. Oktober 2016. Java wird ungültig, sobald ein neues Release mit verbesserter Sicherheit verfügbar wird. Bei Systemen, die nicht auf Oracle Server zugreifen können, läuft diese JRE (Version 8u101) auf Basis eines alternativen Mechanismus am 19. November 2016 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von Java durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren.

» 8u101-Versionshinweise

Java 8 Update 91 (8u91)

Releasehauptmerkmale

IANA Data 2016a
JDK 8u91 enthält Version 2016a der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.
Bugfix: Regression in Applet-Startzeit korrigiert
JDK-8080977 hat eine Verzögerung beim Applet-Start eingeführt. Die Verzögerung tritt nur bei IE auf und dauert ca. 20 Sekunden. In JDK-8136759 wurde diese Verzögerung beseitigt. Siehe JDK-8136759.
Bugfix: DSA-Signaturgenerierung wird nun einer Prüfung der Schlüsselstärke unterzogen
Wenn die Sicherheitsstärke des Digestalgorithmus bei der Signaturgenerierung schwächer als die Sicherheitsstärke des Schlüssels ist, mit dem die Signatur signiert wird (Beispiel: bei (2048, 256)-Bit-DSA-Schlüsseln mit SHA1withDSA-Signatur), ist der Vorgang mit folgender Fehlermeldung nicht erfolgreich: "Die Sicherheitsstärke des SHA1-Digestalgorithmus ist für diese Schlüsselgröße nicht ausreichend". JDK-8138593 (nicht allgemein zugänglich)
Bugfix: Problem mit Firefox 42-Liveconnect
Da dies zu einem Aufhängen des Browsers führen könnte, werden keine JavaScript-zu-Java-Aufrufe verarbeitet, wenn das Java-Plug-in aus plugin-container.exe gestartet wird (das Standardverhalten bei Firefox 42) und der Applet-Status nicht "Bereit" (2) lautet. Wenn das Applet nicht bereit ist (der Status nicht 2 lautet), wird die eigentliche Java-Methode nicht ausgeführt, und es wird nur ein Nullwert zurückgegeben.

Wenn das Plug-in aus plugin-container.exe gestartet wird, verwenden Sie keine JavaScript-zu-Java-Aufrufe, die länger als 11 Sekunden dauern könnten (der Standardwert von dom.ipc.plugins.hangUITimeoutSecs), und zeigen Sie während des JavaScript-zu-Java-Aufrufs kein modales Dialogfeld an. In diesem Fall muss der Hauptbrowserthread blockiert werden, der dazu führen könnte, dass der Browser sich aufhängt und das Plug-in beendet wird.

Workaround für Firefox 42: Benutzer können dom.ipc.plugins.enabled=false festlegen. Bei diesem Workaround wird die Einstellung aber für alle Plug-ins geändert. JDK-8144079 (nicht allgemein zugänglich)
Bugfix: Neues Attribut für JMX-RMI-JRMP-Server gibt eine Liste mit Klassennamen für die Deserialisierung von Serverzugangsdaten an
Ein neues Java-Attribut wurde für die Umgebung definiert, damit ein JMX-RMI-JRMP-Server eine Liste mit Klassennamen angeben kann. Diese Namen entsprechen dem Abschluss von Klassennamen, die bei der Deserialisierung von Zugangsdaten vom Server erwartet werden. Beispiel: Wenn als Zugangsdaten ein
```
 List<string>
```
erwartet wird, entspricht der Abschluss allen konkreten Klassen, die in der seriellen Form einer Zeichenfolgenliste zu erwarten sind.

Standardmäßig wird dieses Attribut nur vom Standard-Agent mit Folgendem verwendet:
```
 { "[Ljava.lang.String;", "java.lang.String" } 
```
Nur Arrays von Zeichenfolgen und Zeichenfolgen werden beim Deserialisieren der Zugangsdaten akzeptiert. Der Attributname lautet:
```
"jmx.remote.rmi.server.credential.types" 
```
Im folgenden Beispiel startet ein Benutzer einen Server mit den angegebenen Zugangsdaten-Klassennamen:
```
 Map<string, object=""> env = new HashMap<>(1); env.put ( "jmx.remote.rmi.server.credential.types", new String[]{ String[].class.getName(), String.class.getName() } ); JMXConnectorServer server = JMXConnectorServerFactory.newJMXConnectorServer(url, env, mbeanServer); 
```
Verwenden Sie das neue Feature, indem Sie direkt Folgendes angeben:
"jmx.remote.rmi.server.credential.types"

JDK-8144430 (nicht allgemein zugänglich)
Bugfix: MD5withRSA-Signaturalgorithmus im JSSE-Provider deaktivieren
Der MD5withRSA-Signaturalgorithmus gilt jetzt als unsicher und sollte nicht mehr verwendet werden. Deshalb wurde MD5withRSA standardmäßig in der Oracle JSSE-Implementierung deaktiviert, indem "MD5withRSA" zur Sicherheitseigenschaft "jdk.tls.disabledAlgorithms" hinzugefügt wurde. Sowohl TLS-Handshake-Nachrichten als auch X.509-Zertifikate, die mit dem MD5withRSA-Algorithmus signiert sind, werden jetzt standardmäßig nicht mehr akzeptiert. Diese Änderung erweitert die vorherige MD5-basierte Zertifikatseinschränkung ("jdk.certpath.disabledAlgorithms") und umfasst jetzt auch Handshake-Nachrichten in TLS-Version 1.2. Bei Bedarf kann dieser Algorithmus wieder aktiviert werden, indem Sie "MD5withRSA" aus der Sicherheitseigenschaft "jdk.tls.disabledAlgorithms" entfernen. JDK-8144773 (nicht allgemein zugänglich)
Bugfix: Neue Zertifikate wurden zu Root-CAs hinzugefügt
Acht neue Root-Zertifikate wurden hinzugefügt:
- QuoVadis Root CA 1 G3 Alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM
- QuoVadis Root CA 2 G3 Alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3
- QuoVadis Root CA 3 G3 Alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM
- DigiCert Assured ID Root G2 Alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US
- DigiCert Assured ID Root G3 Alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US
- DigiCert Global Root G2 Alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US
- DigiCert Global Root G3 Alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US
- DigiCert Trusted Root G4 Alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US
Siehe JDK-8145954 und JDK-8145955.

Hinweise

Entfernen von statischen JREs
Statisch installierte JREs wurden von Java-Installationsprogrammen für Windows, die vor Version 8u91 freigegeben wurden, nicht standardmäßig entfernt. Um statisch installierte JREs zu entfernen, mussten Benutzer diese JREs manuell in der Benutzeroberfläche des Java-Installationsprogramms auswählen. Jetzt werden in Java-Releases 8u91 und höher JREs, die statisch installiert wurden, automatisch entfernt, wenn sie unter der Sicherheits-Baseline liegen. Weitere Informationen zur statischen Installation finden Sie unter Konfiguration von Java Runtime Environment.

Java-Ablaufdatum

Das Ablaufdatum für 8u91 ist der 19. Juli 2016. Java wird ungültig, sobald ein neues Release mit verbesserter Sicherheit verfügbar wird. Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u91) auf Basis eines alternativen Mechanismus am 19. August 2016 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von Java durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren.

Bugfixes

» 8u91-Versionshinweise

Java 8 Update 77 (8u77)

Releasehauptmerkmale

IANA Data 2016a
JDK 8u77 enthält Version 2016a der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.

Java-Ablaufdatum

Ablaufdatum für 8u77 ist der 19. April 2016. Java wird ungültig, sobald ein neues Release mit verbesserter Sicherheit verfügbar wird. Bei Systemen, die nicht auf Oracle Server zugreifen können, läuft diese JRE (Version 8u77) auf Basis eines alternativen Verfahrens am 19. Mai 2016 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von Java durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren.

Hinweise

Dieser Sicherheitshinweis (8u77) basiert auf dem früheren 8u74 PSU-Release. Alle Benutzer des früheren JDK 8-Releases sollten auf dieses Release aktualisieren. Weitere Informationen zum Unterschied zwischen kritischen Patchupdates und Patchsetupdates finden Sie unter Erklärungen zu den Java-CPU- und PSU-Releases.

Die Demos, Stichproben und Dokumentationsbundles für 8u77 sind nicht vom Sicherheitshinweis für CVE-2016-0636 betroffen. Die Demos, Stichproben und Dokumentationsbundles der Version 8u73 bleiben somit bis zum Critical Patch Update-Release im April die aktuellste Version.

Bugfixes

Dieses Release enthält Korrekturen zum Schließen von Sicherheitslücken. Weitere Informationen finden Sie in Oracle Java SE Critical Patch Update Advisory.

» 8u77-Versionshinweise

Java 8 Update 73 (8u73)

Releasehauptmerkmale

IANA Data 2015g
JDK 8u71 enthält Version 2015g der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.

Java-Ablaufdatum

Ablaufdatum für 8u73 ist der 19. April 2016. Java wird ungültig, sobald ein neues Release mit verbesserter Sicherheit verfügbar wird. Bei Systemen, die nicht auf Oracle Server zugreifen können, läuft diese JRE (Version 8u73) auf Basis eines alternativen Verfahrens am 19. Mai 2016 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von Java durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren.

Hinweise

Für Java-Benutzer, die betroffene Versionen heruntergeladen haben und künftige Installationen mit diesen heruntergeladenen Versionen planen, empfiehlt Oracle unbedingt, diese alten Downloads zu verwerfen. Für Java-Benutzer, die die Critical Patch Update-Versionen für Java SE 6, 7 oder 8 vom Januar 2016 installiert haben, ist keine Maßnahme erforderlich. Java-Benutzer, die die Critical Patch Update-Versionen für Java SE 6, 7 oder 8 vom Januar 2016 nicht installiert haben, müssen ein Upgrade auf die Releases Java SE 6, 7 oder 8 über den Sicherheitsalert für CVE-2016-0603 durchführen.

Die Demos, Stichproben und Dokumentationsbundles für 8u73 sind nicht vom Sicherheitsalert für CVE-2016-0603 betroffen. Die Demos, Stichproben und Dokumentationsbundles der Version 8u71 bleiben somit bis zur kritischen Patchupdate-Version im April die aktuellste Version.

Bugfixes

Dieses Release enthält Korrekturen zum Schließen von Sicherheitslücken. Weitere Informationen finden Sie in Oracle Java SE Critical Patch Update Advisory. 8u73 enthält nicht die PSU-Builds, die in 8u72 enthalten sind. Kunden, die die in 8u72 enthaltenen zusätzlichen Bugfixes benötigen, müssen anstatt auf 8u73 auf 8u74 updaten.

» 8u73-Versionshinweise

Java 8 Update 71 (8u71)

Releasehauptmerkmale

IANA Data 2015g
JDK 8u71 enthält Version 2015g der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.
Bugfix: Wenn jps als Root ausgeführt wird, werden nicht alle Informationen angezeigt
Nach dem Fix von JDK-8050807 (in 8u31, 7u75 und 6u91) wurden bei Ausführung von jps als Root bei einigen Systemen nicht alle Informationen aus Java-Prozessen angezeigt, die von anderen Benutzern gestartet wurden. Dies wurde nun korrigiert. Siehe JDK-8075773.
Bugfix: Installationsprogramme scheinen in ESC-Konfigurationen blockiert zu sein
Bei Benutzern, die Internet Explorer Enhance Security Configuration (ESC) auf Windows Server 2008 R2 ausführen, sind möglicherweise Probleme bei der Installation von Java im interaktiven Modus aufgetreten. Dieses Problem wurde in Release 8u71 behoben. Installationsprogramme, die im interaktiven Modus ausgeführt werden, sind in ESC-Konfigurationen nicht mehr blockiert. Siehe JDK-8140197.
Bugfix: Problem bei PBE-Algorithmen, die AES-Kryptografie verwenden, behoben
Ein Fehler bei PBE, der 256-Bit AES-Ciphers verwendet, wurde behoben, sodass der abgeleitete Schlüssel nicht identisch und gleichbedeutend mit Schlüsseln ist, die vorher von demselben Kennwort abgeleitet wurden. JDK-8138589 (nicht allgemein zugänglich)
Bugfix: Standardgrenzwert für maximale XML-Entitygröße hinzugefügt
Ein Standardgrenzwert für die maximale Entitygröße wurde hinzugefügt. Weitere Informationen zu XML-Verarbeitungsgrenzwerten finden Sie in The Java Tutorials, Processing Limits. JDK-8133962 (nicht allgemein zugänglich)
Bugfix: Problem bei Dokumentation zu 'REMOVEOLDERJRES' für Enterprise MSI-Switch behoben
In der Enterprise MSI-Dokumentation werden Konfigurationsoptionen aufgeführt. Die Option REMOVEOLDERJRES zur Deinstallation alter JREs hat gefehlt. Diese Option wurde mit folgender Beschreibung hinzugefügt:
If set to 1, removes older releases of the JRE installed on the system (Wenn dieser Wert auf 1 festgelegt ist, werden ältere Releases von JRE entfernt, die auf dem System installiert sind).
Default: 0 does not remove any old JREs (Standardwert: 0 entfernt keine alten JREs)
JDK-8081237 (nicht allgemein zugänglich)

Java-Ablaufdatum

Ablaufdatum für 8u71 ist der 19. April 2016. Java wird ungültig, sobald ein neues Release mit verbesserter Sicherheit verfügbar wird. Bei Systemen, die nicht auf Oracle Server zugreifen können, läuft dieses JRE (Version 8u71) auf Basis eines alternativen Verfahrens am 19. Mai 2016 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von Java durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren.

Bugfixes

Dieses Release enthält Korrekturen zum Schließen von Sicherheitslücken. Weitere Informationen finden Sie in Oracle Java SE Critical Patch Update Advisory.

Eine Liste der in diesem Release enthaltenen Bugfixes finden Sie auf der Seite JDK 8u71-Bugfixes.

» 8u71-Versionshinweise

Java 8 Update 66 (8u66)

Releasehauptmerkmale

8u66 Build 18 behebt ein Problem mit Firefox.

Bugfix: _releaseObject wird aus falschem Thread aufgerufen
Durch eine kürzlich in Firefox vorgenommene Änderung wird _releaseObject von einem anderen als dem Hauptthread aufgerufen. Dadurch kann es zu einer Race-Bedingung kommen, die versehentliche Browserabstürze verursachen kann. Dieses Problem wird in Build 18 von 8u66 behoben. Weitere Informationen finden Sie unter Bugs@Mozilla 1221448. Siehe JDK-8133523.

Java-Plug-in funktioniert nach der Installation von Java nicht in Firefox

Firefox 42 kann abstürzen, wenn Sie versuchen, das Java-Plug-in auszuführen Workaround-Optionen werden in den FAQ (Häufig gestellten Fragen) aufgeführt. Siehe JDK-8142908 (nicht allgemein zugänglich).

Java-Ablaufdatum

Das Ablaufdatum für 8u66 ist der 19. Januar 2016. Java wird ungültig, sobald ein neues Release mit verbesserter Sicherheit verfügbar wird. Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u66) auf Basis eines alternativen Mechanismus am 19. Februar 2016 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von Java durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren.

Bugfixes

Dieses Release enthält Korrekturen zum Schließen von Sicherheitslücken. Weitere Informationen finden Sie in Oracle Java SE Critical Patch Update Advisory.

Eine Liste der in diesem Release enthaltenen Bugfixes finden Sie auf der Seite JDK 8u66 Bug Fixes.

» 8u66-Versionshinweise

Java 8 Update 65 (8u65)

Releasehauptmerkmale

IANA Data 2015f
JDK 8u65 enthält Version 2015f der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.
Unterstützung für ISO 4217 Tabelle "Aktuelle Währungscodes" (A.2)
Diese Verbesserung fügt Unterstützung für die ISO 4217-Währungscodes der Tabelle A.2 hinzu. Zuvor hat das JDK lediglich die in Tabelle A.1 aufgelisteten Währungen unterstützt. Siehe JDK-8074350.
Bugfix: [Mac OS X] Update des installierten JRE-AU-Clients auf NEXTVER unter Mac 10.11 ist nicht erfolgreich
Im Release 8u65 wird ein neues Installationsprogramm eingeführt, mit dem OS X-Benutzer ein Update auf die aktuellste Version vornehmen können. Das Installationsprogramm gilt sowohl für geplante als auch für manuelle Updates sowie für Bundles, die auf java.com und in OTN verfügbar gemacht werden. Benutzer, bei denen es zu Kompatibilitätsproblemen mit dem neuen Installationsprogramm kommt, können das in My Oracle Support verfügbare PKG-Installationsprogramm manuell herunterladen und installieren.
Bugfix: Hotspot sollte PICL-Schnittstelle verwenden, um Cachezeilengröße bei SPARC abzurufen
Die libpicl-Library ist jetzt bei Solaris/SPARC erforderlich, um die Größe der Cachezeilen zu bestimmen. Falls die Library nicht vorhanden oder der PICL-Service nicht verfügbar ist, zeigt die JVM eine Warnung an, und Compiler-Optimierungen, die die BIS-(Block Initializing Store-)Anweisung verwenden, werden ausgeschaltet. Siehe JDK-8056124.
Bugfix: dns_lookup_realm muss standardmäßig "false" sein
Die dns_lookup_realm-Einstellung in der Kerberos-Datei krb5.conf ist standardmäßig "false". Siehe JDK-8080637.
Bugfix: Das Vorabladen von libjsig.dylib führt zu Deadlock, wenn signal() aufgerufen wird
Anwendungen müssen die libjsig-Library vorab laden, um die Signalverkettung zu aktivieren. Zuvor hat jeder Aufruf von nativem Code zu signal() bei OS X nach dem Vorabladen von libjsig.dylib zu Deadlock geführt. Dies wurde korrigiert. Siehe JDK-8072147.
Bugfix: Bessere Gruppendynamik
In OpenJDK SSL/TLS/DTLS-Implementierung (SunJSSE-Provider) werden standardmäßig Diffie-Hellman-Gruppen mit sicheren Primzahlen verwendet. Benutzer können Diffie-Hellman-Gruppen über die Sicherheitseigenschaft jdk.tls.server.defaultDHEParameters anpassen.
Bugfix: VM-Absturz bei Neudefinition der Klasse mit Instrumentation.redefineClasses
Die JVM konnte abstürzen, wenn eine Klasse mit Instrumentation.redefineClasses() neu definiert wurde. Beim Absturz konnte es sich entweder um einen Segmentierungsfault bei SystemDictionary::resolve_or_null oder um einen internen Fehler mit der Meldung "Tagkonflikt mit Auflösungsfehlertabelle" handeln. Dies wurde nun korrigiert. Siehe JDK-8076110.

Hinweise

Bei Ausführung unter OSX 10.11 El Capitan und Aktivierung von SIP können bestimmte Umgebungsvariablen für das Debugging von Anwendungen, wie DYLD_LIBRARY_PATH aus der Umgebung entfernt werden, wenn Sie Java über die Befehlszeile ausführen oder auf eine JAR-Datei doppelklicken. Diese Variablen dürfen in einer Production-Umgebung nicht für Anwendungen erforderlich sein, sie dienen lediglich zum Debuggen während der Entwicklung.

MD5 darf nicht für digitale Signaturen verwendet werden, wenn der Kollisionswiderstand erforderlich ist. Um die Verwendung von MD5 als Algorithmus für digitale Signaturen bei X.509-Zertifikatsvorgängen zu verhindern, wird MD5 der Sicherheitseigenschaft jdk.certpath.disabledAlgorithms hinzugefügt. Bei Anwendungen, die noch immer mit MD5 signierte Zertifikate verwenden, müssen Sie das schwache Zertifikat so bald wie möglich upgraden.

Bekannte Probleme

[Mac OS X] Probleme mit Barrierefreiheit für Bildschirm mit Sponsorenangeboten (a11y)
Benutzer, die mit der Tastatur auf Benutzeroberflächen im Java-Installationsprogramm zugreifen, können nicht auf Hyperlinks und Kontrollkästchen in Bildschirmen mit Software-Add-on-Angeboten zugreifen. Als Workaround zum Festlegen von Voreinstellungen für Add-on-Software in der Benutzeroberfläche können Benutzer derartige Angebote deaktivieren, indem Sie sie entweder im Java Control Panel deaktivieren oder SPONSORS=0 über die Befehlszeile übergeben. Weitere Informationen finden Sie in den häufig gestellten Fragen unter Java ohne kostenlose Angebote installieren. Siehe JDK-8061886 (nicht allgemein zugänglich).

Java-Ablaufdatum

Das Ablaufdatum für 8u65 ist der 19. Januar 2016. Java wird ungültig, sobald ein neues Release mit verbesserter Sicherheit verfügbar wird. Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u65) auf Basis eines alternativen Mechanismus am 19. Februar 2016 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von Java durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren.

Bugfixes

Dieses Release enthält Korrekturen zum Schließen von Sicherheitslücken. Weitere Informationen finden Sie in Oracle Java SE Critical Patch Update Advisory.

Eine Liste der in diesem Release enthaltenen Bugfixes finden Sie auf der Seite JDK 8u65 Bug Fixes.

» 8u65-Versionshinweise

Java 8 Update 60 (8u60)

Releasehauptmerkmale

IANA Data 2015e
JDK 8u51 enthält Version 2015e der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.
Bugfix: dns_lookup_realm muss standardmäßig "false" sein
Die dns_lookup_realm-Einstellung in der Kerberos-Datei krb5.conf ist standardmäßig false. Siehe 8080637.
Bugfix: RC4-Cipher-Suites deaktivieren
RC4-basierte TLS-Cipher-Suites (Beispiel: TLS_RSA_WITH_RC4_128_SHA) werden jetzt als gefährdet betrachtet und sollten nicht mehr verwendet werden (siehe RFC 7465) Deshalb wurden RC4-basierte TLS-Cipher-Suites standardmäßig in der Oracle JSSE-Implementierung deaktiviert, indem "RC4" zu der "jdk.tls.disabledAlgorithms"-Sicherheitseigenschaft hinzugefügt wurde, und indem diese aus der Liste der standardmäßig aktivierten Cipher Suites entfernt wurden. Diese Cipher Suites können reaktiviert werden, indem "RC4" aus der "jdk.tls.disabledAlgorithms"-Sicherheitseigenschaft in der java.security-Datei entfernt wird oder indem Security.setProperty() dynamisch aufgerufen wird, und auch indem diese wieder zu der Liste der aktivierten Cipher Suites mit den SSLSocket/SSLEngine.setEnabledCipherSuites()-Methoden hinzugefügt werden. Sie können auch die -Djava.security.properties-Befehlszeilenoption verwenden, um die jdk.tls.disabledAlgorithms-Sicherheitseigenschaft außer Kraft zu setzen. Beispiel:
java -Djava.security.properties=my.java.security ...
, wobei my.java.security eine Datei ist, die die Eigenschaft ohne RC4 enthält:
jdk.tls.disabledAlgorithms=SSLv3
Auch wenn diese Option über die Befehlszeile festgelegt wird, müssen die RC4-basierten Cipher Suites über die SSLSocket/SSLEngine.setEnabledCipherSuites()-Methoden erneut zur Liste der aktivierten Cypher Suites hinzugefügt werden. Siehe 8076221.
Bugfix: Unterstützung der Erkennung des Keystore-Typs bei JKS- und PKCS12-Keystores
Keystore-Kompatibilitätsmodus: Aus Kompatibilitätsgründen unterstützt der Java Keystore-Typ JKS jetzt standardmäßig den Keystore-Kompatibilitätsmodus. In diesem Modus können JKS-Keystores sowohl auf JKS- als auch auf PKCS12-Dateiformate zugreifen. Um den Keystore-Kompatibilitätsmodus zu deaktivieren, legen Sie die Sicherheitseigenschaft keystore.type.compat auf den Zeichenfolgenwert false fest. Siehe 8062552.
Bugfix: Unsichere Überwachungsmethoden im JDK 8u-Release nicht mehr unterstützen
Die Methoden monitorEnter monitorExit und tryMonitorEnter in sun.misc.Unsafe werden in JDK 8u60 als veraltet markiert und in einem zukünftigen Release entfernt. Diese Methoden werden nicht innerhalb von JDK selbst verwendet und werden sehr selten außerhalb von JDK verwendet. Siehe 8069302.
Bugfix: JFR-Aufzeichnung aus der Core-Datei mit SA extrahieren
DumpJFR ist ein auf dem Serviceability Agent basierendes Tool, mit dem Java Flight Recorder-(JFR-)Daten aus den Core-Dateien und Live-Hotspot-Prozessen extrahiert werden können. DumpJFR kann in einer der folgenden Methoden verwendet werden:
- DumpJFR an Liveprozess anhängen:
  
  The embedded asset does not exist:
  Asset Type: jWidget_C
  Asset Id: 1371164883097
  PAGENAME: JCOM/jWidget_C/Raw_HTML/Display
- DumpJFR an Coredatei anhängen:
  
  The embedded asset does not exist:
  Asset Type: jWidget_C
  Asset Id: 1371164883117
  PAGENAME: JCOM/jWidget_C/Raw_HTML/Display
Das DumpJFR-Tool gibt die JFR-Daten in eine Datei mit der Bezeichnung recording.jfr im aktuellen Arbeitsordner aus. Siehe 8065301 (nicht allgemein zugänglich).
Bugfix: Lokale Variablen namens "enum" führen zu vereinzelten Compiler-Crashes
Der javac-Parser parst lokale Variablen mit dem Namen "enum" falsch. Dies führt zu vereinzelten Fehlern, wenn ein Programm, das derartige lokale Variablen enthält, mit einem "source"-Flag kompiliert wird, das einem Release entspricht, in dem das enum-Konstrukt nicht verfügbar ist (wie "-source 1.4"). Siehe 8069181.

Java Development Kit für ARM Release 8u60

In diesem Release ist das Java Development Kit für ARM Release 8u60 (JDK 8u60 für ARM) enthalten. Informationen zur ARM-Geräteunterstützung finden Sie auf der Seite JDK for ARM Downloads. Informationen zu Systemanforderungen, Installationsanweisungen und Tipps zur Fehlerbehebung finden Sie auf der Seite Installation Instructions.

Einschränkung: Unterstützung für Native Memory Tracking ist im JDK für ARM eingeschränkt. Die Java-Befehlszeilenoption XX:NativeMemoryTracking=detail wird für ARM-Ziele nicht unterstützt (Benutzern wird eine Fehlermeldung angezeigt). Verwenden Sie stattdessen die folgende Option:
XX:NativeMemoryTracking=summary

Dokumentationsupdates wegen Nashorn-Optimierungen

JDK 8u60 enthält neue Optimierungen bei Nashorn. Deshalb sollten die folgenden Dokumentationsänderungen zusammen mit der aktuellen Nashorn-Dokumentation gelesen werden:

Ergänzung: Im vorherigen Abschnitt haben wir darauf hingewiesen, dass jedes JavaScript-Objekt die java.util.Map-Oberfläche implementiert, wenn es für Java APIs verfügbar gemacht wird. Dies gilt selbst für JavaScript-Arrays. Dieses Behavior ist jedoch häufig unerwünscht oder unerwartet, wenn der Java-Code mit JSON geparste Objekte erwartet. Java-Bibliotheken, die mit JSON geparste Objekte verarbeiten, erwarten im Allgemeinen, dass Arrays die java.util.List-Oberfläche bereitstellen. Wenn Sie die JavaScript-Objekte so bereitstellen müssen, dass Arrays als Listen und nicht als Maps angezeigt werden, können Sie die Java.asJSONCompatible(obj)-Funktion verwenden, wobei obj die Root der JSON-Objektbaumstruktur ist.
Korrektur: Der Achtungsvermerk am Ende des Abschnitts Datentypen zuordnen gilt nicht mehr. Nashorn stellt sicher, dass interne JavaScript-Zeichenfolgen in java.lang.String konvertiert werden, wenn sie extern bereitgestellt werden.
Korrektur: Der Hinweis "Beispiel: Arrays müssen explizit konvertiert werden..." im Abschnitt Datentypen zuordnen ist nicht korrekt. Arrays werden automatisch in Java-Array-Typen konvertiert, wie java.util.List, java.util.Collection, java.util.Queue, java.util.Deque usw.

Änderungen in Deployment-Regelset v1.2

JDK 8u60 implementiert Deployment-Regelset (DRS) 1.2, das die folgenden Änderungen enthält:

Hinzufügen des "checksum"-Elements als Subelement von "id", mit dem nicht signierte JAR-Dateien von der SHA-256-Prüfsumme der nicht komprimierten Form einer JAR identifiziert werden können:
- Das "checksum"-Element wird nur mit unsignierten JARs abgeglichen und der angegebene Hash-Wert wird nur mit der unkomprimierten Form der JAR verglichen.
- Das "checksum"-Element (ähnelt dem "certificate"-Element) enthält die beiden Argumente "hash" und "algorithm". Im Gegensatz zum "certificate"-Element jedoch wird für"algorithm" nur der Wert "SHA-256" unterstützt. Alle anderen angegebenen Werte werden ignoriert.
Das "message"-Element kann für alle Regeltypen angewendet werden, während es vorher nur für eine Blockierungsregel angewendet wurde:
- In einer Ausführungsregel führt ein Meldungs-Subelement zur Anzeige eines Meldungsdialogfeldes, während ohne eine Ausführungsregel standardmäßig ein Dialogfeld mit Zertifikat oder Hinweis auf "Unsigniert" angezeigt wird. Die Meldung wird im Meldungsdialogfeld angezeigt.
- In einer Standardregel wird die Meldung nur angezeigt, wenn die Standardaktion "Blockieren" ist. In diesem Fall wird die Meldung in dem Blockierungsdialogfeld aufgenommen.
"customer"-Blockierungen in der Java-Konsole, in Tracedateien und in Java Usage Tracker-Datensätzen anzeigen.
- Vor DRS 1.2 konnten "customer"-Elemente (mit eventuellen Subelementen) in der Datei ruleset.xml aufgenommen werden. Dieses Element und alle Subelemente werden ignoriert. In DRS 1.2 werden diese Elemente weiterhin funktional ignoriert. Allerdings gilt Folgendes:
  - Beim Parsen der ruleset.xml-Datei werden alle "customer"-Blockierungen auf der Java-Konsole und in der Deployment-Tracedatei ausgegeben (wenn Konsole und Tracing aktiviert sind).
  - Bei Verwendung einer Regel werden alle "customer"-Datensätze, die in dieser Regel enthalten sind, zu dem Java Usage Tracker-(JUT-)Datensatz hinzugefügt (wenn JUT aktiviert ist).

Nach den obigen Änderungen sieht die DTD für DRS 1.2 wie folgt aus:
The embedded asset does not exist:
Asset Type: jWidget_C
Asset Id: 1385352043373
PAGENAME: JCOM/jWidget_C/Raw_HTML/Display

Java-Ablaufdatum

Das Ablaufdatum für 8u60 ist der 20. Oktober 2015. Java wird ungültig, sobald ein neues Release mit verbesserter Sicherheit verfügbar wird. Bei Systemen, die nicht auf Oracle Server zugreifen können, läuft diese JRE (Version 8u60) auf Basis eines alternativen Verfahrens am 20. November 2015 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von Java durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren.

Bugfixes

Eine Liste der in diesem Release enthaltenen Bugfixes finden Sie auf der Seite JDK 8u60 Bug Fixes.

» 8u60-Versionshinweise

Java 8 Update 51 (8u51)

Releasehauptmerkmale

IANA Data 2015d
JDK 8u51 enthält Version 2015d der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.
Bugfix: Neue Comodo-Roots zu Root-CAs hinzugefügt
Vier neue Root-Zertifikate wurden für Comodo hinzugefügt:
1. COMODO ECC Certification Authority alias: comodoeccca DN: CN=COMODO ECC Certification Authority, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB
2. COMODO RSA Certification Authority alias: comodorsaca DN: CN=COMODO RSA Certification Authority, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB
3. USERTrust ECC Certification Authority alias: usertrusteccca DN: CN=USERTrust ECC Certification Authority, O=The USERTRUST Network, L=Jersey City, ST=New Jersey, C=US
4. USERTrust RSA Certification Authority alias: usertrustrsaca DN: CN=USERTrust RSA Certification Authority, O=The USERTRUST Network, L=Jersey City, ST=New Jersey, C=US
Siehe JDK-8077997 (nicht allgemein zugänglich).
Bugfix: Neue GlobalSign-Roots zu Root-CAs hinzugefügt
Zwei neue Root-Zertifikate wurden für GlobalSign hinzugefügt:
1. GlobalSign ECC Root CA - R4 alias: globalsigneccrootcar4 DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4
2. GlobalSign ECC Root CA - R5 alias: globalsigneccrootcar5 DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R5
Siehe JDK-8077995 (nicht allgemein zugänglich).
Bugfix: Actalis zu Root-CAs hinzugefügt
Ein neues Root-Zertifikat wurde hinzugefügt:
Actalis Authentication Root CA alias: actalisauthenticationrootca DN: CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT
Siehe JDK-8077903 (nicht allgemein zugänglich).
Bugfix: Neue Entrust ECC-Root hinzugefügt
Ein neues Root-Zertifikat wurde hinzugefügt:
Entrust Root Certification Authority - EC1 alias: entrustrootcaec1 DN: CN=Entrust Root Certification Authority - EC1, OU="(c) 2012 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US
Siehe JDK-8073286 (nicht allgemein zugänglich).
Bugfix: Alte Valicert Class 1 und 2 Policy-Roots entfernt
Zwei Root-Zertifikate mit 1024-Bit-Schlüsseln wurden entfernt:
1. ValiCert Class 1 Policy Validation Authority alias: secomvalicertclass1ca DN: EMAILADDRESS=info@valicert.com, CN=http://www.valicert.com/, OU=ValiCert Class 1 Policy Validation Authority, O="ValiCert, Inc.", L=ValiCert Validation Network
2. ValiCert Class 2 Policy Validation Authority alias: valicertclass2ca DN: EMAILADDRESS=info@valicert.com, CN=http://www.valicert.com/, OU=ValiCert Class 2 Policy Validation Authority, O="ValiCert, Inc.", L=ValiCert Validation Network
Siehe JDK-8077886 (nicht allgemein zugänglich).
Bugfix: Alte Thawte-Roots entfernt
Zwei Root-Zertifikate mit 1024-Bit-Schlüsseln wurden entfernt:
1. Thawte Server CA alias: thawteserverca DN: EMAILADDRESS=server-certs@thawte.com, CN=Thawte Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
2. Thawte Personal Freemail CA alias: thawtepersonalfreemailca DN: EMAILADDRESS=personal-freemail@thawte.com, CN=Thawte Personal Freemail CA, OU=Certification Services Division, O=Thawte Consulting, L=Cape Town, ST=Western Cape, C=ZA
Siehe JDK-8074423 (nicht allgemein zugänglich).
Bugfix: Weitere alte Verisign-, Equifax- und Thawte-Roots entfernt
Fünf Root-Zertifikate mit 1024-Bit-Schlüsseln wurden entfernt:
1. Verisign Class 3 Public Primary Certification Authority - G2 alias: verisignclass3g2ca DN: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
2. Thawte Premium Server CA alias: thawtepremiumserverca DN: EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
3. Equifax Secure Certificate Authority alias: equifaxsecureca DN: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
4. Equifax Secure eBusiness CA-1 alias: equifaxsecureebusinessca1 DN: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US
5. Equifax Secure Global eBusiness CA-1, alias: equifaxsecureglobalebusinessca1 DN: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US
Siehe JDK-8076202 (nicht allgemein zugänglich).
Bugfix: TrustCenter-CA-Roots aus cacerts entfernt
Drei Root-Zertifikate wurden entfernt:
1. TC TrustCenter Universal CA I alias: trustcenteruniversalcai DN: CN=TC TrustCenter Universal CA I, OU=TC TrustCenter Universal CA, O=TC TrustCenter GmbH, C=DE
2. TC TrustCenter Class 2 CA II alias: trustcenterclass2caii DN: CN=TC TrustCenter Class 2 CA II, OU=TC TrustCenter Class 2 CA, O=TC TrustCenter GmbH, C=DE
3. TC TrustCenter Class 4 CA II alias: trustcenterclass4caii DN: CN=TC TrustCenter Class 4 CA II, OU=TC TrustCenter Class 4 CA, O=TC TrustCenter GmbH, C=DE
Siehe JDK-8072958 (nicht allgemein zugänglich).
Bugfix: RC4 in SunJSSE-Provider als veraltet einstufen
RC4 gilt jetzt als schwache Cipher. Server sollten nur dann RC4 verwenden, wenn kein stärkerer Kandidat in den vom Client angeforderten Cipher Suites vorhanden ist. Die neue Sicherheitseigenschaft jdk.tls.legacyAlgorithms wurde hinzugefügt, um die Legacy-Algorithmen in der Oracle JSSE-Implementierung zu definieren. Zu RC4 gehörige Algorithmen werden der Legacy-Algorithmenliste hinzugefügt. Siehe JDK-8074006 (nicht allgemein zugänglich).
Bugfix: RC4-Cipher-Suites untersagen
RC4 gilt jetzt als gefährdete Cipher. RC4-Cipher-Suites wurden aus der Liste der standardmäßig für Clients und Server aktivierten Cipher Suites in der Oracle JSSE-Implementierung entfernt. Diese Cipher Suites können weiterhin mit den Methoden SSLEngine.setEnabledCipherSuites() und SSLSocket.setEnabledCipherSuites() aktiviert werden. Siehe JDK-8077109 (nicht allgemein zugänglich).
Bugfix: Verbesserte Zertifikatsprüfung
Aufgrund dieses Fix wird bei der JSSE-Endpunktidentifizierung standardmäßig kein Reverse Name Lookup für IP-Adressen in JDK ausgeführt. Wenn ein Reverse Name Lookup für rohe IP-Adressen in SSL/TLS-Verbindungen bei einer Anwendung erforderlich ist und ein Kompatibilitätsproblem mit der Endpunktidentifizierung auftritt, können Sie mit der Systemeigenschaft "jdk.tls.trustNameService" das Reverse Name Lookup einschalten. Wenn der Name Service nicht vertrauenswürdig ist, kann die Aktivierung des Reverse Name Lookups für MITM-Angriffe anfällig sein. Siehe JDK-8067695 (nicht allgemein zugänglich).

Java-Ablaufdatum

Das Ablaufdatum für 8u51 ist der 20. Oktober 2015. Java wird ungültig, sobald ein neues Release mit verbesserter Sicherheit verfügbar wird. Bei Systemen, die nicht auf Oracle Server zugreifen können, läuft diese JRE (Version 8u51) auf Basis eines alternativen Mechanismus am 20. November 2015 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von Java durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren.

Bugfixes

Dieses Release enthält Korrekturen zum Schließen von Sicherheitslücken. Weitere Informationen finden Sie in Oracle Java SE Critical Patch Update Advisory.

Eine Liste der in diesem Release enthaltenen Bugfixes finden Sie auf der Seite JDK 8u51 Bug Fixes.

» 8u51-Versionshinweise

Java 8 Update 45 (8u45)

Releasehauptmerkmale

IANA Data 2015a
JDK 8u45 enthält Version 2015a der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.
Bugfix: Handling von JAR-Dateien verbessern. Ab Release JDK 8u45 lässt das jar-Tool beim Erstellen von neuen ZIP-oder JAR-Dateien oder beim Extrahieren von Dateien aus ZIP- oder JAR-Dateien die Verwendung des Schrägstrichs (/) gefolgt von zwei Punkten (..) als Pfadkomponenten in Dateinamen für ZIP-Einträge nicht mehr zu. Falls erforderlich, muss die neue Befehlszeilenoption "-P" verwendet werden, um die durch zwei Punkte bezeichnete und/oder die absolute Pfadkomponente ausdrücklich beizubehalten. Siehe 8064601 (nicht allgemein zugänglich).
Bugfix: Beim Laden einer JNLP-Anwendung mit verschachteltem Abschnitt "resource" in jre8u40 tritt ein NPE-Fehler auf. Eine JNLP-Anwendung mit -Tags, die in einem <java>- oder -Tag verschachtelt sind, kann einen NPE-Fehler auslösen. Das Problem ist jetzt behoben. Das -Tag darf nur verwendet werden, wenn das <java>-Tag tatsächlich verwendet wird. Siehe 8072631 (nicht allgemein zugänglich).

Java-Ablaufdatum

Das Ablaufdatum für 8u45 ist der 14. Juli 2015. Java wird ungültig, sobald ein neues Release mit verbesserter Sicherheit verfügbar wird. Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u45) auf Basis eines alternativen Mechanismus am 14. August 2015 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von Java durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren.

Bugfixes

Dieses Release enthält Korrekturen zum Schließen von Sicherheitslücken. Weitere Informationen finden Sie in Oracle Java SE Critical Patch Update Advisory.

Eine Liste der in diesem Release enthaltenen Bugkorrekturen finden Sie auf der Seite JDK 8u45 Bug Fixes.

» 8u45-Versionshinweise

Java 8 Update 40 (8u40)

Releasehauptmerkmale

IANA Data 2014j
JDK 8u40 enthält Version 2014j der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.
Bugfix: Standard- und statische Schnittstellenmethoden in JDI, JDWP und JDB. Seit JDK 8 sind direkt ausführbare statische und Standardmethoden in Schnittstellen möglich. Diese Methoden können nicht über JDWP oder JDI ausgeführt werden, deshalb ist ein ordnungsgemäßes Debugging nicht möglich. Weitere Informationen finden Sie im JDK 8 Compatibility Guide. Siehe 8042123.
Bugkorrektur: Java Access Bridge kann für 32-Bit-JREs über Control Panel aktiviert werden. Das Kontrollkästchen "Java Access Bridge aktivieren" wurde vormals über die 64-Bit-JRE-Deinstallation aus dem Java Control Panel entfernt, auch wenn das 32-Bit-JRE noch auf dem System vorhanden war. Ab Release JDK 8u40 wird das Kontrollkästchen "Java Access Bridge aktivieren" unter Systemsteuerung -> Erleichterte Bedienung -> Center für erleichterte Bedienung -> Computer ohne einen Bildschirm verwenden beibehalten, wenn ein 32-Bit-JRE vorhanden ist. Benutzer können Java Access Bridge also über die Systemsteuerung aktivieren. Siehe 8030124.
Bugkorrektur: JavaFX-Medienstack auf Mac OS X modernisieren. Den JavaFX-Medien wird eine auf AVFoundation basierende Spielerplattform hinzugefügt. Die alte, QTKit-basierte Plattform kann jetzt zwecks Mac App Store-Kompatibilität entfernt werden. Siehe 8043697 (nicht allgemein zugänglich)
Bugkorrektur: Fehlende DOM-APIs. In JDK-Release 8u40 wurden die alten DOM-APIs für das Plug-in unbeabsichtigt entfernt. Wenn ein Applet com.sun.java.browser.dom.DOMService für die Kommunikation mit dem Browser erfordert, müssen Benutzer das Applet möglicherweise für die Verwendung von netscape.javascript.JSObject aktualisieren oder weiterhin JDK 8 Update 31 verwenden. Dieses Problem wurde in Build 26 behoben. Für 8u40 wurden neue Installationsprogramme veröffentlicht. Wenn Sie dieses Problem feststellen, laden Sie die aktualisierten Installationsprogramme für JDK 8u40 herunter, und führen Sie sie aus. Siehe 8074564.
Bugkorrektur: Mac 10.10: Bei der Ausführung von Anwendungen mit Startbildschirm treten Fokusprobleme auf. Über Webstart gestartete Anwendungen oder Standalone-Anwendungen, die einen Startbildschirm verwenden, erreichen keinen Tastaturfokus. Workaround: Starten Sie javaws mit der Option -Xnosplash. Dieses Problem wurde in Build 27 behoben. Für 8u40 wurde ein neues Installationsprogramm veröffentlicht. Wenn Sie dieses Problem feststellen, laden Sie das aktualisierte Installationsprogramm für JDK 8u40 herunter, und führen Sie es aus. Siehe 8074668.
Verbesserungen am Java Packager-Tool
Release JDK 8u40 enthält folgende Verbesserungen an Java Packager:
- Befehlszeilenargumente können an eigenständige Anwendungen übergeben werden. Beim Erstellen des Package werden Standardargumente definiert. Diese können dann vom Benutzer beim Starten der Anwendung außer Kraft gesetzt werden.
- Dateiverknüpfungen können eingerichtet werden, wenn eine eigenständige Anwendung installiert wird, sodass die Anwendungen für registrierte Dateierweiterungen oder MIME-Typen automatisch ausgeführt wird.
- Die UserJvmOptionsService-API steht für die Änderung von JVM-Optionen in eigenständigen Anwendungen zur Verfügung. Die neuen Einstellungen treten beim nächsten Start der Anwendung in Kraft.
- Für eigenständige Anwendungen werden mehrere Einstiegspunkte unterstützt. Dadurch kann eine Produktsuite in dasselbe Anwendungspackage gebündelt werden.
Veraltete APIs
Der Mechanismus Unterstützte Standards außer Kraft setzen sowie der Erweiterungsmechanismus sind veraltet und werden in einem zukünftigen Release möglicherweise entfernt. Es finden keine Laufzeitänderungen statt. Für vorhandene Anwendungen, die die Mechanismen "Unterstützte Standards außer Kraft setzen" oder "Erweiterung" verwenden, wird eine Migration von der Verwendung dieser Mechanismen weg empfohlen. Zur Identifizierung aller vorhandenen Verwendungen dieser Mechanismen steht die Befehlszeilenoption -XX:+CheckEndorsedAndExtDirs zur Verfügung. Diese Option ist nicht erfolgreich, wenn eine der folgenden Bedingungen den Wert "true" hat:
- die Systemeigenschaft -Djava.endorsed.dirs oder -Djava.ext.dirs ist so eingestellt, dass der Standardspeicherort geändert wird, oder
- das Verzeichnis ${java.home}/lib/endorsed ist vorhanden, oder
- ${java.home}/lib/ext enthält andere JAR-Dateien als die im JDK mitgelieferten, oder
- ein plattformspezifisches systemweites Erweiterungsverzeichnis enthält JAR-Dateien.
Die Befehlszeilenoption -XX:+CheckEndorsedAndExtDirs wird in JDK 8u40 und späteren Releases unterstützt.
Unterschiede bei der JJS-Toolseite
Die japanische Version der JJS-Hilfeseite weicht von der englischen Version ab. Einige der nicht unterstützten Optionen wurden aus der englischen Version der Toolseite jjs entfernt. Die japanische Version des Dokuments wird zu einem späteren Zeitpunkt aktualisiert. Siehe 8062100 (nicht allgemein zugänglich). Weitere Änderungen an der JJS-Toolseite finden Sie unter Tools Enhancements in JDK 8.
Änderungen an den Standardwerten für G1HeapWastePercent und G1MixedGCLiveThresholdPercent
Der Standardwert für G1HeapWastePercent wurde von 10 in 5 geändert, um den Bedarf an vollständigen GCs zu senken. Aus demselben Grund wurde der Standardwert für G1MixedGCLiveThresholdPercent von 65 auf 85 geändert.
Neue Schnittstelle zum Filtern des Zugriffs auf Java-Klassen
Mit der Schnittstelle jdk.nashorn.api.scripting.ClassFilter können Sie den Zugriff auf bestimmte Java-Klassen über Skripte, die über die Skript-Engine Nashorn ausgeführt werden, einschränken. Weitere Informationen finden Sie im Nashorn User's Guide unter Restricting Script Access to Specified Java Classes und unter "8043717 (nicht allgemein zugänglich)".
Probleme mit JCE-Providern von Drittanbietern
Durch den Fix für JDK-8023069 (in JDK 8u20) wurden sowohl der SunJSSE- als auch der SunJCE-Provider aktualisiert, einschließlich einiger interner Schnittstellen. Einige andere JCE-Provider (Beispiel: RSA JSAFE) verwenden einige sun.* internal-Schnittstellen und funktionieren daher nicht mit dem aktualisierten SunJSSE-Provider. Solche Provider werden nicht aktualisiert, damit sie mit dem aktualisierten SunJSSE-Provider funktionieren. Wenn Sie von diesem Problem betroffen sind, wenden Sie sich an Ihren JCE-Händler, um ein Update zu erhalten. Siehe 8058731.
Verschlüsselungen in Solaris Crypto Framework erneut aktiviert
Für Benutzer von Solaris 10 wurde eine Änderung vorgenommen, um Vorgänge mit MD5, SHA1 und SHA2 über das Solaris Crypto Framework erneut zu aktivieren. Wenn bei Ihnen mit JDK 8u40 eine CloneNotSupportedException oder die PKCS11-Fehlermeldung CKR_SAVED_STATE_INVALID auftritt, prüfen Sie die nachfolgenden Patches oder neuere Versionen davon, und spielen Sie sie ein:
- 150531-02 auf SPARC
- 150636-01 auf x86
Troubleshooting Guide-Updates für NMT
NMT (Native Memory Tracking) ist ein Java Hotspot VM-Feature, das die interne Speichernutzung für eine HotSpot-JVM verfolgt. Mit NMT können interne VM-Speicherzuordnungen überwacht und VM-Speicherlecks diagnostiziert werden. Die NMT-Features werden in die Seite mit den VM-Verbesserungen aufgenommen. Siehe Java Virtual Machine Enhancements in Java SE 8. Die NMT-Features werden in den Troubleshooting Guide aufgenommen. Siehe Native Memory Tracking.
Feature zum Starten mehrerer JREs als veraltet eingestuft
Das Feature zur Auswahl der JRE-Version zur Startzeit bzw. zum Starten mehrerer JREs ist in JDK 8u40 veraltet. Anwendungen, bei denen spezifische Java-Versionen mit diesem Feature bereitgestellt werden müssen, müssen zu anderen Deployment-Lösungen wechseln, wie Java WebStart.
JavaFX-Verbesserungen
Ab JDK-Release 8u40 unterstützen JavaFX-Steuerelemente assistive Technologien, d.h. JavaFX-Steuerelemente sind jetzt barrierefrei. Außerdem wird eine allgemein zugängliche API bereitgestellt, mit der Entwickler ihre eigenen barrierefreien Steuerelemente schreiben können. Auf Windows- und Mac OS X-Plattformen wird die Barrierefreiheit unterstützt, die Folgendes umfasst:
- Unterstützung für das Lesen von JavaFX-Steuerelementen mit einer Bildschirmsprachausgabe
- JavaFX-Steuerelemente können über die Tastatur weitergegeben werden
- Unterstützung eines besonders kontrastreichen Modus, mit dem Steuerelemente für Benutzer besser sichtbar werden.
Siehe 8043344 (nicht allgemein zugänglich).

Das JDK-Release 8u40 umfasst neue JavaFX UI-Steuerelemente, ein Drehfeldsteuerelement, Unterstützung für formatierten Text und ein Standardset von Alert-Dialogfeldern.
- Drehfeldsteuerelement: Ein Drehfeld ist ein einzeiliges Textfeld, mit dem der Benutzer einen Zahlen- oder Objektwert aus einer geordneten Folge wählen kann. Weitere Informationen finden Sie unter javafx.scene.control.Spinner-Klasse.
- Formatierter Text: Eine neue TextFormatter-Klasse stellt Textformatierungsfunktionen für Unterklassen von TextInputControl bereit (Beispiel: TextField und TextArea). Weitere Informationen finden Sie unter javafx.scene.control.TextFormatter-Klasse.
- Dialoge: Die Dialog-Klasse lässt zu, dass Anwendungen ihre eigenen benutzerdefinierten Dialoge erstellen. Außerdem wird eine Alertklasse bereitgestellt, die die Dialog-Klasse erweitert und eine Reihe von vordefinierten Dialogtypen unterstützt, mit denen Benutzer jederzeit zur Eingabe einer Antwort aufgefordert werden können. Weitere Informationen finden Sie in den Klassen javafx.scene.control.Dialog, javafx.scene.control.Alert, javafx.scene.control.TextInputDialog und javafx.scene.control.ChoiceDialog.
Siehe 8043350 (nicht allgemein zugänglich).

Gewerbliche Features

Application Class Data Sharing (AppCDS)
Application Class Data Sharing (AppCDS) erweitert CDS, damit Sie Klassen aus den Verzeichnissen für Standarderweiterungen und dem Anwendungs-Classpath im gemeinsam genutzten Archiv ablegen können. Hierbei handelt es sich um ein experimentelles Feature, das nicht für die kommerzielle Nutzung lizenziert ist. Siehe Option -XX:+UseAppCDS auf der Toolseite des Java-Launchers.
Kooperative Speicherverwaltung
Ab JDK 8u40 gibt es in JDK das Konzept der "Speicherauslastung". Speicherdruck ist eine Eigenschaft, die die gesamte Speichernutzung (RAM) im System darstellt. Je höher der Speicherdruck, desto näher rückt der Moment, an dem dem System der Speicher ausgeht. Hierbei handelt es sich um ein experimentelles Feature, das nicht für die kommerzielle Nutzung lizenziert ist. Als Reaktion auf den erhöhten Speicherdruck versucht das JDK, seine Speichernutzung zu senken. Dies geschieht größtenteils durch eine Senkung der Java-Heap-Größe. Die vom JDK zur Senkung der Speichernutzung durchgeführten Maßnahmen können zu einer Verschlechterung der Performance führen. Dies ist so beabsichtigt. Der Druckpegel wird von der Anwendung über ein JMX MXBean bereitgestellt, das eine Skala von 0 (kein Druck) bis 10 (nicht genügend Speicher) verwendet. Um dieses Feature zu aktivieren, muss das jdk.management.cmm.SystemResourcePressureMXBean registriert werden. Der Speicherdruck wird dann über das Attribut "MemoryPressure" festgelegt.
Ein neues Befehlszeilen-Flag -XX:MemoryRestriction, das die Argumente "none", "low", "medium" oder "high" haben kann, ist ebenfalls verfügbar. Dieses Flag legt den anfänglichen Druck im JDK fest und funktioniert auch in Fällen, in denen das MXBean nicht registriert ist. Für die kooperative Speicherverwaltung ist G1 GC (-XX:+UseG1GC) erforderlich. Dieses Feature ist nicht mit dem Flag -XX:+ExplicitGCInvokesConcurrent kompatibel.
Neue gewerbliche Flags
Für Inhaber gewerblicher Lizenzen sind jetzt zwei neue VM-Optionen verfügbar:
- -XX:+ResourceManagement
- -XX:ResourceManagementSampleInterval=value (Millisekunden)
Weitere Informationen finden Sie in der Dokumentation zu Java Launcher.
Neue Dokumentation zu MSI Installer:
Der Microsoft Windows Installer (MSI) Enterprise JRE Installer Guide ist jetzt verfügbar. Zum Einsatz in Production-Umgebungen ist für den MSI Enterprise JRE Installer eine gewerbliche Lizenz erforderlich. Weitere Informationen zu gewerblichen Features und deren Aktivierung.

Java-Ablaufdatum

Ablaufdatum für 8u40 ist der 14. April 2015. Java wird ungültig, sobald ein neues Release mit verbesserter Sicherheit verfügbar wird. Bei Systemen, die nicht auf Oracle Server zugreifen können, wird dieses JRE (Version 8u40) auf Basis eines alternativen Mechanismus am 14. Mai 2015 entkräftigt. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von Java durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren.

Bugfixes

Eine Liste der in diesem Release enthaltenen Bugkorrekturen finden Sie auf der Seite JDK 8u40 Bug Fixes.

» 8u40-Versionshinweise

Java 8 Update 31 (8u31)

Releasehauptmerkmale

IANA Data 2014j
JDK 8u31 enthält Version 2014j der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.
SSLv3 ist standardmäßig deaktiviert
Ab JDK-Release 8u31 ist das SSLv3-Protokoll (Secure Socket Layer) deaktiviert und normalerweise nicht verfügbar. Weitere Informationen finden Sie in der Eigenschaft jdk.tls.disabledAlgorithms in der Datei \lib\security\java.security. Wenn SSLv3 unbedingt erforderlich ist, kann das Protokoll reaktiviert werden, indem "SSLv3" aus der Eigenschaft jdk.tls.disabledAlgorithms in der Datei java.security entfernt wird oder indem diese Sicherheitseigenschaft vor der Initialisierung von JSSE dynamisch festgelegt wird.
Änderungen an Java Control Panel
Ab JDK-Release 8u31 ist das SSLv3-Protokoll in den Optionen in Java Control Panel - Advanced nicht mehr vorhanden. Wenn der Benutzer SSLv3 für Anwendungen verwenden muss, kann SSLv3 wie folgt manuell erneut aktiviert werden:
- Aktivieren Sie das SSLv3-Protokoll auf JRE-Ebene: wie im vorherigen Abschnitt beschrieben.
- Aktivieren Sie das SSLv3-Protokoll auf Deployment-Ebene: Bearbeiten Sie die Datei deployment.properties, und fügen Sie Folgendes hinzu:
  
  deployment.security.SSLv3=true

Java-Ablaufdatum

Ablaufdatum für 8u31 ist der 14. April 2015. Java wird ungültig, sobald ein neues Release mit verbesserter Sicherheit verfügbar wird. Bei Systemen, die nicht auf Oracle Server zugreifen können, läuft diese JRE (Version 8u31) auf Basis eines alternativen Verfahrens am 14. Mai 2015 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von Java durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren.

Bugfixes

Dieses Release enthält Korrekturen zum Schließen von Sicherheitslücken. Weitere Informationen finden Sie in Oracle Java SE Critical Patch Update Advisory.

Eine Liste der in diesem Release enthaltenen Bugkorrekturen finden Sie auf der Seite JDK 8u31 Bug Fixes.

» 8u31-Versionshinweise

Java 8 Update 25 (8u25)

Releasehauptmerkmale

IANA Data 2014c
JDK 8u25 enthält Version 2014c der IANA-Zeitzonendaten. Weitere Informationen finden Sie unter Timezone Data Versions in the JRE Software.
Bugfix: Voreinstellungsmodus von RC4 in aktivierter Cipher-Suite-Liste verringern
Dieser Fix verringert die Voreinstellung von RC4-basierten Cipher Suites in der standardmäßig aktivierten Cipher-Suite-Liste des SunJSSE-Providers. Siehe 8043200 (nicht allgemein zugänglich).
Bugfix: JRE 8u20 stürzt bei Verwendung japanischer IM unter Windows ab
Bei Verwendung von Swing-Steuerelementen stürzt die VM ab, wenn einige japanische oder chinesische Zeichen auf Windows-Plattformen eingegeben werden. Das Problem ist jetzt behoben. Siehe 8058858 (nicht allgemein zugänglich).

Anweisungen zum Deaktivieren von SSL 3.0 in Oracle JDK und JRE

Oracle empfiehlt, dass Benutzer und Entwickler die Verwendung des Protokolls SSL 3.0 deaktivieren.
» Wie können Java-Benutzer herausfinden, ob sie von der Sicherheitslücke "Poodle" in SSL 3.0 betroffen sind?

Java-Ablaufdatum

Das Ablaufdatum für 8u25 ist der 20. Januar 2015. Java wird ungültig, sobald ein neues Release mit verbesserter Sicherheit verfügbar wird. Bei Systemen, die nicht auf Oracle-Server zugreifen können, läuft diese JRE (Version 8u25) auf Basis eines alternativen Mechanismus am 20. Februar 2015 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von Java durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren.

Bugfixes

Dieses Release enthält Korrekturen zum Schließen von Sicherheitslücken. Weitere Informationen finden Sie in Oracle Java SE Critical Patch Update Advisory.

Eine Liste der in diesem Release enthaltenen Bugfixes finden Sie auf der Seite JDK 8u25 Bug Fixes.

» 8u25-Versionshinweise

Java 8 Update 20 (8u20)

Releasehauptmerkmale

Neue Flags zur Java Management-API hinzugefügt
Die Flags MinHeapFreeRatio und MaxHeapFreeRatio können jetzt verwaltet werden. Das bedeutet, dass sie zur Laufzeit über die Management-API in Java geändert werden können. Unterstützung für diese Flags wurde auch zu ParallelGC als Teil der adaptiven Größen-Policy hinzugefügt.
Änderungen bei Java-Installationsprogramm
- Ein neuer Microsoft Windows Installer (MSI) Enterprise JRE Installer ist verfügbar, mit dem JRE unternehmensweit installiert werden kann. Weitere Informationen finden Sie im Abschnitt Installer herunterladen in JRE-Installation für Microsoft Windows. Der MSI Enterprise JRE Installer ist nur als Bestandteil von Java SE Advanced oder Java SE Suite verfügbar. Weitere Informationen zu diesen kommerziellen Produkten finden Sie unter Java SE Advanced und Java SE Suite.
- Das Java-Deinstallationstool ist in dem Installationsprogramm integriert, damit ältere Java-Versionen aus dem System entfernt werden können. Die Änderung gilt für 32-Bit- und 64-Bit-Versionen der Windows-Plattform. Siehe JRE deinstallieren.
Änderungen bei Java Control Panel
- Mit der Registerkarte Update im Java Control Panel können Benutzer jetzt automatisch 64-Bit-JREs (zusätzlich zu 32-Bit-Versionen) aktualisieren, die auf ihrem System installiert sind.
- Die Sicherheitsebene Mittel wurde entfernt. Jetzt sind nur die Ebenen Hoch und Sehr hoch verfügbar. Die Ausführung von Applets, die die neuesten Sicherheitsrichtlinien nicht erfüllen, kann dennoch genehmigt werden, indem die Sites, die diese Applets hosten, in der Ausnahmeliste aufgenommen werden. Durch die Ausnahmeliste können Benutzer dieselben Applets zuzulassen, die bei Auswahl der Option Mittel zugelassen worden wären, allerdings pro Site, sodass das Risiko der Verwendung weiterreichender Einstellungen vermindert wird.
Java-Compiler aktualisiert
Der javac-Compiler wurde aktualisiert, um die definitive Zuweisungsanalyse für den Zugriff auf ein leeres "final"-Feld mit "this" zu implementieren. Weitere Informationen finden Sie im JDK 8 Compatibility Guide.
Änderung bei der minimal erforderlichen Java-Version für Java Plugin und Java Webstart
Für Java Plugin und Java Webstart ist jetzt mindestens Java 5 erforderlich. Applets, die nicht in Java 5 oder höher ausgeführt werden, müssen zu einer höheren Java-Version portiert werden, damit sie weiter funktionieren. Applets, die für frühere Versionen geschrieben wurden, jedoch mindestens in Java 5 ausgeführt werden können, funktionieren weiterhin.
Änderung bei der Formatierung der UsageTracker-Ausgabe
Die Formatierung der UsageTracker-Ausgabe wurde geändert und verwendet jetzt Anführungszeichen, um Verwechslungen im Log zu vermeiden. Dies kann Änderungen bei der Art erforderlich machen, wie diese Informationen gelesen werden. Die Funktion kann so konfiguriert werden, dass sie sich wie in früheren Versionen verhält, obwohl das neue Format empfohlen wird. Weitere Informationen finden Sie in der Java UsageTracker-Dokumentation.
Änderungen an Java Packaging-Tools
- javafxpackager wurde in javapackager umbenannt
- Die Option "-B" wurde dem "deploy"-Befehl von javapackager hinzugefügt, damit Sie Argumente an die Bundler übergeben können, die für das Erstellen von eigenständigen Anwendungen verwendet werden. Weitere Informationen finden Sie in der Dokumentation zu javapackager (Windows)/(Unix)
- Das Argument des Hilfsprogrammparameters wurde zu JavaFX Ant Task Reference hinzugefügt. Mit ihm können Sie ein Argument (im -Element) für den Bundler angeben, das beim Erstellen eigenständiger Anwendungen verwendet wird.

Java-Ablaufdatum

Das Ablaufdatum für 8u20 ist der 14. Oktober 2014. Java wird ungültig, sobald ein neues Release mit verbesserter Sicherheit verfügbar wird. Bei Systemen, die nicht auf Oracle Server zugreifen können, läuft diese JRE (Version 8u20) auf Basis eines alternativen Mechanismus am 14. November 2014 ab. Wenn eine der beiden Bedingungen erfüllt wird (eine neue Version wird verfügbar/Ablaufdatum erreicht), werden Benutzer von Java durch weitere Warnungen und Erinnerungen aufgefordert, auf die neuere Version zu aktualisieren.

Bugfixes

Eine Liste der in diesem Release enthaltenen Bugfixes finden Sie auf der Seite JDK 8u20 Bug Fixes.

» 8u20-Versionshinweise

Java 8 Update 11 (8u11)

Dieses Release enthält Korrekturen zum Schließen von Sicherheitslücken. Weitere Informationen finden Sie in Oracle Critical Patch Update Advisory.

Eine Liste der in diesem Release enthaltenen Bugfixes finden Sie auf der Seite JDK 8u11 Bug Fixes.

» 8u11-Versionshinweise

Java 8 Update 5 (8u5)

Dieses Release enthält Korrekturen zum Schließen von Sicherheitslücken. Weitere Informationen finden Sie in Oracle Critical Patch Update Advisory.

Eine Liste der in diesem Release enthaltenen Bugfixes finden Sie auf der Seite JDK 8u5 Bug Fixes.

» 8u5-Versionshinweise

Java 8 Release

» JDK- und JRE 8-Versionshinweise