Java.com

Download Hilfe

Druckversion

Java 8-Releasehauptmerkmale


Dieser Artikel gilt für:
  • 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 Versionshinweisen für jedes Release.
» Java-Releasedaten


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: Systemeigenschaft
    jdk.tls.namedGroups(null) enthält keine unterstützten elliptischen Kurven


    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 zur Überprüfung von MD5-signierten JAR-Dateien eingeführt. Wenn die signierte JAR-Datei MD5 verwendet, ignoriert die Signaturüberprüfung 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 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 kryptographisch 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 zur 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, würde Folgendes ausgegeben werden:

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

    Weitere Einzelheiten erhalten Sie, wenn Sie die Verbose-Option verwenden:

    jarsigner -verify -verbose test.jar

    Es würde Folgendes ausgegeben werden:

    - 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 in regelmäßigen Abständen 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)
  • Die neue Version von VisualVM
    VisualVM 1.3.9 wurde am 4. Oktober 2016 freigegeben http://visualvm.github.io/relnotes.html und in 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. Sie können diese Einschränkungen für Anwendungen 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 öffentlich)
  • 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 nicht definierter 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 eine ähnliche 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-Remote-Klassen

Das Laden von Remote-Klassen über JNDI-Objekt-Factorys, die im Naming Service und Directory Service gespeichert sind, ist standardmäßig deaktiviert. Um das Laden von Remote-Klassen 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.

Insbesondere beim Aufruf von "jarsigner -verify -verbose filename.jar" wird ein separater Abschnitt gedruckt, 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.disabledAlgorithms als schwach angesehen wird, wird er mit "(weak)" ((schwach)) 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
IllegalArgumentException beim TLS-Handshake

Ein vor Kurzem aufgetretenes Problem bei der JDK-8173783-Korrektur kann bei einigen TLS-Servern Probleme hervorrufen. Grund des Problems ist eine IllegalArgumentException, die durch den TLS-Handshaker-Code hervorgerufen wird.

java.lang.IllegalArgumentException: Systemeigenschaft
jdk.tls.namedGroups(null) enthält keine unterstützten elliptischen Kurven

Das Problem kann auftreten, wenn der Server keine Elliptische-Kurven-Kryptografie unterstützt, um das Erweiterungsfeld des Namens einer elliptischen Kurve zu handhaben (sofern vorhanden). Benutzern wird empfohlen, ein Upgrade auf dieses Release durchzuführen. Standardmäßig werden JDK 7-Updates und höhere JDK-Familien mit dem SunEC-Sicherheitsprovider geliefert, der die Unterstützung für die Elliptische-Kurven-Kryptografie bereitstellt. Diese Releases sind nur betroffen, wenn die Sicherheitsprovider geändert werden. Siehe JDK-8173783

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<Zahl>.tmp) im %TEMP%-Verzeichnis.
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.security beschrieben. 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

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 8u121 Bug Fixes.

» 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 Signaturprüfung 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 zur 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:
    "Signature not parsable or verifiable". (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. Für weitere Informationen 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. 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 in regelmäßigen Abständen 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 Ihre JARs mit MD5 signiert wurden, fügen Sie MD5 zu der jdk.jar.disabledAlgorithms-Sicherheitseigenschaft hinzu. Beispiel:

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

    . Danach führen Sie jarsigner -verify -J-Djava.security.debug=jar für Ihre 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:
  1. hotspot/jvm/os/processor/cpu_load
  2. 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

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 8u111 Bug Fixes.

» 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. Code eines Fremdherstellers, der mit einem installierten SecurityManager ausgeführt wird, jedoch die neue Berechtigung beim Aufruf von Util.createValueHandler() nicht hat, wird mit einer AccessControlException 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.

    Als solches erfordern externe Anwendungen, die javax.rmi.CORBA.Util.createValueHandler explizit aufrufen, eine Konfigurationsänderung, damit sie funktionieren, wenn ein SecurityManager installiert ist 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 wird zu jarsigner hinzugefügt, um den Message-Digest-Algorithmus anzugeben, der zur Generierung des Nachrichten-Imprints verwendet 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)

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.

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 8u101 Bug Fixes.

» 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 verarbeitet, und es wird nur null 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), oder zeigen Sie kein modales Dialogfeld während des JavaScript-zu-Java-Aufrufs 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, um zuzulassen, dass 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
Java-Installationsprogramme für Windows, die vor Version 8u91 freigegeben wurden, haben statisch installierte JREs 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

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 Bugfixes für JDK 8u91.

» 8u91-Versionshinweise


Java 8 Update 77 (8u77)

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 Critical Patch Updates und Patch Set Updates 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-Releasehinweise


Java 8 Update 73 (8u73)

Releasehauptmerkmale
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 Sicherheits-Alert für CVE-2016-0603 durchführen.

Die Demos, Stichproben und Dokumentationsbundles für 8u73 sind nicht vom Sicherheits-Alert 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, so dass 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 Release notes


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.

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 Ciphersuites über die SSLSocket/SSLEngine.setEnabledCipherSuites()-Methoden erneut zur Liste der aktivierten Cybersuites 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ützt
    Die Methoden monitorEnter, monitorExit und tryMonitorEnter in sun.misc.Unsafe werden in JDK 8u60 als veraltet markiert und werden 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 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 einem Liveprozess zuordnen:

      java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.tools.DumpJFR <pid>

    • DumpJFR einer Core-Datei zuordnen:

      java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.tools.DumpJFR <java> <core>
    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 und 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 (das dem "certificate"-Element ähnlich ist) enthält zwei Argumente "hash" und "algorithm", im Gegensatz zu dem "certificate"-Element wird jedoch nur der Wert "SHA-256" für "algorithm" 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).
Als Folge der oben aufgeführten Änderungen sieht die DTD für DRS 1.2 folgendermaßen aus:
<!ELEMENT ruleset (rule*)>
<!ATTRIBUTE ruleset href CDATA #IMPLIED>
<!ATTRIBUTE ruleset version CDATA #REQUIRED>

<!ELEMENT rule (id, action)>

<!ELEMENT id (certificate?) (checksum?) >
<!ATTRIBUTE id title CDATA #IMPLIED>
<!ATTRIBUTE id location CDATA #IMPLIED>

<!ELEMENT certificate EMPTY>
<!ATTLIST certificate algorithm CDATA #IMPLIED>
<!ATTLIST certificate hash CDATA #REQUIRED>

<!ELEMENT checksum EMPTY>
<!ATTLIST checksum algorithm CDATA #IMPLIED>
<!ATTLIST checksum hash CDATA #REQUIRED>
 
<!ELEMENT action (message?)>
<!ATTRIBUTE permission (run | block | default) #REQUIRED>
<!ATTRIBUTE version CDATA #IMPLIED>
<!ATTRIBUTE force (true|false) "false">

<!ELEMENT message (#PCDATA)>
<!ATTLIST message locale CDATA #IMPLIED>

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-Releasehinweise


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 hinzufügen
    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 hinzufügen
    Vier 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 hinzufügen
    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 hinzufügen
    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 Policy Roots von Valicert Class 1 und 2 entfernen
    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 entfernen
    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 entfernen
    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 entfernen
    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 dieser Korrektur wird bei der JSSE-Endpunktidentifizierung standardmäßig kein Reverse Name Lookup für IP-Adressen in JDK vorgenommen. 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: Handhabung 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 <resources>-Tags, die in einem <java>- oder <j2se>-Tag verschachtelt sind, kann einen NPE-Fehler auslösen. Das Problem ist jetzt behoben. Das <resources>-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-Releasehinweise


Java 8 Update 40 (8u40)

Releasehauptmerkmale
  • IANA Data 2014
    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:
  • 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 an 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 auf 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 anderen JCE-Providern
    Durch die Korrektur 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.
  • Erneut aktivierte Verschlüsselungen in Solaris Crypto Framework
    Für Nutzer 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 ist veraltet
    Das Feature zur Auswahl der JRE-Version zur Startzeit bzw. zum Starten mehrerer JREs wie dokumentiert 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-Erweiterungen
    Ab JDK 8u40 Release wurden JavaFX-Steuerelemente erweitert und unterstützen Hilfstechnologien, d.h. auf JavaFX-Steuerelemente kann jetzt zugegriffen werden. 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).

    JDK 8u40-Release umfasst neue JavaFX UI-Steuerelemente; ein Drehfeldsteuerelement, Unterstützung von formatiertem Text und ein Standardset mit 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 Alert-Klasse 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 javafx.scene.control.Dialog, javafx.scene.control.Alert, javafx.scene.control.TextInputDialog, javafx.scene.control.ChoiceDialog-Klassen.
    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 wird das Konzept des "Speicherdrucks" für JDK eingeführt. 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 "keine", "niedrig", "mittel" oder "hoch" 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.
  • Dokumentation zu MSI Installer hinzugefügt
    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 2014
    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 dem JDK 8u31-Release wurde das SSLv3-Protokoll (Secure Socket Layer) deaktiviert und ist normalerweise nicht verfügbar. Weiter Informationen erhalten Sie in der Eigenschaft jdk.tls.disabledAlgorithms in der Datei <JRE_HOME>\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 dem JDK 8u31-Release wird das SSLv3-Protokoll aus den Optionen Java Control Panel Advanced entfernt. 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 Deploy-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
    Diese Korrektur 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 und implementiert die bestimmte Zuweisungsanalyse für ein leeres "final"-Feld mit "this". 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 Zitatzeichen, 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 <fx:bundleArgument> des Hilfsprogrammparameters wurde zu JavaFX Ant Task Reference hinzugefügt. Mit ihm können Sie ein Argument (im <fx:deploy>-Element) für den Bundler angeben, der beim Erstellen von eigenständigen 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


Folgende Themen könnten ebenfalls interessant für Sie sein:




Sprachauswahl | Info zu Java | Support | Entwickler
Datenschutz  | Nutzungsbedingungen | Marken | Haftungsausschluss

Oracle