Laden Sie Java MSI x64 und x86 herunter 8.0.1910.12.
Zur Installation mit Configuration Manager verwenden:
x86
msiexec.exe /i "jre1.8.0_191.msi" /qn JU=0 JAVAUPDATE=0 AUTOUPDATECHECK=0 RebootYesNo=No
x64
msiexec.exe /i "jre1.8.0_19164.msi" /qn JU=0 JAVAUPDATE=0 AUTOUPDATECHECK=0 RebootYesNo=No
Zur Deinstallation verwenden:
x86
msiexec /x {26A24AE4-039D-4CA4-87B4-2F32180191F0} /qn /norestart
x64
msiexec /x {26A24AE4-039D-4CA4-87B4-2F64180191F0} /qn /norestart
Release-Highlights
Neue Eigenschaften
Infrastruktur/Bau
Build-Umgebungs-Update Linux x86/x64 Auf gcc 7.3 verschobenUnter x86/x64-Linux, Die zum Erstellen des JDK verwendete Toolchain wurde von GCC aktualisiert 4.3 zu GCC 7.3.
Änderungen
core-svc
Der Speicherort im zentralen Dateisystem für die Datei „usagetracker.properties“ wurde geändertDer Dateisystemspeicherort in Windows fürusagetracker.properties
Die Datei wurde verschoben%ProgramData%\Oracle\Java\
Zu%ProgramFiles%\Java\conf
Für Linux gibt es keine Änderung am Dateipfad, Solaris, oder macOS.
security-libs/javax.net.ssl
Alle DES TLS Cipher Suites deaktiviertDES-basierte TLS-Verschlüsselungssammlungen gelten als veraltet und sollten nicht mehr verwendet werden. DES-basierte Cipher Suites wurden in der SunJSSE-Implementierung standardmäßig deaktiviert, indem das hinzugefügt wurde “DES” Identifikator für diejdk.tls.disabledAlgorithms
Sicherheitseigentum. Diese Cipher-Suites können durch Entfernen reaktiviert werden “DES” von demjdk.tls.disabledAlgorithms
Sicherheitseigentum in derjava.security
Datei oder durch dynamisches Aufrufen derSecurity.setProperty()
Methode. In beiden Fällen muss nach der erneuten Aktivierung von DES DES-basierte Cipher-Suites mithilfe von zur Liste der aktivierten Cipher-Suites hinzugefügt werdenSSLSocket.setEnabledCipherSuites()
oderSSLEngine.setEnabledCipherSuites()
Methoden.
Beachten Sie dies vor dieser Änderung, DES40_CBC (aber nicht alle DES) Suiten wurden über das deaktiviertjdk.tls.disabledAlgorithms
Sicherheitseigentum.
security-libs/java.security
Entfernung mehrerer Symantec-Root-CAsDie folgenden Symantec-Stammzertifikate werden nicht mehr verwendet und wurden entfernt:
- Symantec
- equifaxsecurecaDN: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
- equifaxsecureglobalebusinessca1DN: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US
- equifaxsecureebusinessca1DN: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US
- verisignclass1g3caDN: CN=VeriSign-Klasse 1 Öffentliche primäre Zertifizierungsstelle – G3, ODER=”(C) 1999 VeriSign, Inc. – Nur zur autorisierten Verwendung”, OU=VeriSign Trust Network, O=”VeriSign, Inc.”, C=US
- verisignclass2g3caDN: CN=VeriSign-Klasse 2 Öffentliche primäre Zertifizierungsstelle – G3, ODER=”(C) 1999 VeriSign, Inc. – Nur zur autorisierten Verwendung”, OU=VeriSign Trust Network, O=”VeriSign, Inc.”, C=US
- verisignclass1g2caDN: OU=VeriSign Trust Network, ODER=”(C) 1998 VeriSign, Inc. – Nur zur autorisierten Verwendung”, OU=Klasse 1 Öffentliche primäre Zertifizierungsstelle – G2, O=”VeriSign, Inc.”, C=US
- verisignclass1caDN: OU=Klasse 1 Öffentliche primäre Zertifizierungsstelle, O=”VeriSign, Inc.”, C=US
security-libs/java.security
Entfernung von Baltimore Cybertrust Code Signing CADas folgende Baltimore CyberTrust Code Signing-Stammzertifikat wird nicht mehr verwendet und wurde entfernt:
- baltimorecodesigningcaDN: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE
security-libs/java.security
Entfernung des SECOM-Root-ZertifikatsDas folgende SECOM-Stammzertifikat wird nicht mehr verwendet und wurde entfernt:
- secomevrootca1DN: OU=Sicherheitskommunikation EV RootCA1, O=”SECOM Trust Systems CO.,LTD.”, C=JP
Hotspot/Laufzeit
Java-Verbesserungen für Docker-ContainerDie folgenden Änderungen wurden im JDK eingeführt 10 um die Ausführung und Konfigurierbarkeit von Java zu verbessern, das in Docker-Containern ausgeführt wird:
- JDK-8146115 Verbessert die Erkennung von Docker-Containern und die Nutzung der Ressourcenkonfiguration
Die JVM wurde geändert, um zu erkennen, dass sie in einem Docker-Container ausgeführt wird und containerspezifische Konfigurationsinformationen extrahiert, anstatt das Betriebssystem abzufragen. Die extrahierten Informationen sind die Anzahl der CPUs und der Gesamtspeicher, die dem Container zugewiesen wurden. Die Gesamtzahl der für den Java-Prozess verfügbaren CPUs wird aus allen angegebenen CPU-Sets berechnet, CPU-Anteile oder CPU-Quoten. Diese Unterstützung ist nur auf Linux-basierten Plattformen verfügbar. Diese neue Unterstützung ist standardmäßig aktiviert und kann in der Befehlszeile mit der JVM-Option deaktiviert werden:
-XX:-UseContainerSupport
Zusätzlich, Diese Änderung fügt eine JVM-Option hinzu, die die Möglichkeit bietet, die Anzahl der CPUs anzugeben, die die JVM verwenden wird:
-XX:ActiveProcessorCount=count
Diese Zählung überschreibt alle anderen automatischen CPU-Erkennungslogiken in der JVM.
- JDK-8186248 Ermöglicht mehr Flexibilität bei der Auswahl von Heap % des verfügbaren RAM
Drei neue JVM-Optionen wurden hinzugefügt, um Benutzern von Docker-Containern eine detailliertere Kontrolle über die Menge an Systemspeicher zu ermöglichen, die für den Java-Heap verwendet wird:
-XX:InitialRAMPercentage
-XX:MaxRAMPercentage
-XX:MinRAMPercentage
Diese Optionen ersetzen die veralteten Bruchformen (-XX:InitialRAMFraction
, -XX:MaxRAMFraction
, Und-XX:MinRAMFraction
).
- Das Anhängen von JDK-8179498 unter Linux sollte relativ zu /proc/pid/root und Namespace-fähig sein
Diese Fehlerbehebung korrigiert den Anhängemechanismus, wenn versucht wird, eine Verbindung von einem Hostprozess zu einem Java-Prozess herzustellen, der in einem Docker-Container ausgeführt wird.
security-libs/javax.crypto
Verbesserte VerschlüsselungseingabenDie Spezifikation vonjavax.crypto.CipherInputStream
wurde klargestellt, um anzuzeigen, dass diese Klasse BadPaddingException und andere Ausnahmen abfangen kann, die durch fehlgeschlagene Integritätsprüfungen während der Entschlüsselung ausgelöst werden. Diese Ausnahmen werden nicht erneut ausgelöst, Daher wird der Kunde möglicherweise nicht darüber informiert, dass die Integritätsprüfung fehlgeschlagen ist. Aufgrund dieses Verhaltens, Diese Klasse ist möglicherweise nicht für die Verwendung mit Entschlüsselung in einem authentifizierten Betriebsmodus geeignet (z.B. GCM). Anwendungen, die eine authentifizierte Verschlüsselung erfordern, können alternativ zur Verwendung dieser Klasse direkt die Cipher-API verwenden.
Fehlerbehebung
Im Folgenden sind einige der bemerkenswerten Fehlerbehebungen aufgeführt, die in dieser Version enthalten sind:
core-libs/javax.naming
LDAPS-KommunikationsfehlerAnwendungscode, der LDAPS mit einem Socket-Verbindungs-Timeout verwendet <= 0 ( der Standardwert ) Beim Verbindungsaufbau kann es zu einer Ausnahme kommen.
Die obersten Frames von Ausnahme-Stack-Traces von Anwendungen, bei denen solche Probleme auftreten, könnten wie folgt aussehen:
javax.naming.ServiceUnavailableException: <server:port>; socket closed
at com.sun.jndi.ldap.Connection.readReply(Unknown Source)
at com.sun.jndi.ldap.LdapClient.ldapBind(Unknown Source)
...
core-libs/java.net
Bessere HTTP-UmleitungsunterstützungIn dieser Version, das Verhalten von Methoden, die der Anwendungscode zum Festlegen von Anforderungseigenschaften verwendetjava.net.HttpURLConnection
hat sich verändert. Wenn eine Umleitung automatisch vom ursprünglichen Zielserver zu einer Ressource auf einem anderen Server erfolgt, Anschließend werden alle diese Eigenschaften für die Umleitung und alle nachfolgenden Weiterleitungen gelöscht. Wenn diese Eigenschaften für die umgeleiteten Anforderungen festgelegt werden müssen, Dann sollten die Umleitungsantworten von der Anwendung durch Aufruf verarbeitet werdenHttpURLConnection.setInstanceFollowRedirects(false)
für die ursprüngliche Anfrage.