Versionskommentarer till Java 8

Viktiga ändringar i Java 8

Denna artikel gäller för:

Plattformar: Inga
Webbläsare: Inga
Java-versioner: 8.0

På den här sidan beskrivs de ändringar i varje Java-version som påverkar slutanvändare. Du hittar mer information om ändringarna i versionsinformationen för varje utgåva.
» Datum för Java-utgåvor

Java 8 uppdatering 441 (8u441)

Viktiga funktioner i versionen

JDK 8u441 innehåller IANA-tidszonsdata för 2024a.
Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
JavaFX är inte längre inkluderat i JDK/JRE 8
Denna utgåva, JDK och JRE 8 uppdatering 441, är den sista utgåvan som paketerar JavaFX. Som vi meddelade 2020 kommer stöd för JavaFX på JDK 8, den sista versionen av JavaFX med kommersiellt stöd, upphöra att gälla i mars 2025. Därmed är JDK 8 uppdatering 441 den sista uppgraderingen av JDK/JRE 8 med JavaFX. Oracle fortsätter att utveckla och ge ut JavaFX som fristående moduler via det öppna JFX-projektet för de senaste versionerna av Java. Se Java SE vår 2024 uppdatering av vägkarta för mer information.
Övriga anteckningar: Stöd för tidszondatabasen 2024b
IANA Time Zone Database har uppgraderats till 2024b. Denna version inkluderar främst ändringar som förbättrar historiska data för Mexiko, Mongoliet och Portugal. En tidsstämpelförkortning har också ändrats för tidszonen "MET". Ytterligare är Asia/Choibalsan nu alias för Asia/Ulaanbaatar.
Se JDK-8339637

Hålla JDK uppdaterad

Oracle rekommenderar att JDK uppdateras med varje kritisk programfixuppdatering. Du kan använda sidan Säkerhetsbaslinje för att se vilken version som är den senaste för varje versionsfamilj.

Kritiska programfixuppdateringar som innehåller korrigeringar för säkerhetssårbarheter meddelas ett år i förväg i kritiska programfixuppdateringar, säkerhetsaviseringar och rapporter. Vi rekommenderar inte att den här JDK-versionen (version 8u441) används efter nästa kritiska programfixuppdatering som är schemalagd till den 15 april 2025.

Java Management Service är tillgänglig för alla användare och kan hjälpa dig att hitta sårbara Java-versioner i dina system. Java SE-abonnenter och kunder som körs i Oracle Cloud kan använda Java Management Service för att uppdatera Java-exekveringsmiljöer och för att göra ytterligare säkerhetsgranskningar som att identifiera potentiellt sårbara bibliotek från tredje part som används av dina Java-program. Befintlig Java Management Service-användare klicka här för att logga in på din infopanel. Java Management Service-dokumentationeninnehåller en lista över funktioner som är tillgängliga för alla och de som endast är tillgängliga för kunder. läs mer om hur du använder Java Management Service för att övervaka och säkra dina Java-installationer.

För system som inte kan nå Oracle-servrarna finns det en sekundär mekanism som upphör i denna JRE (version 8u441) den 15 maj 2025. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av JRE:n om att uppdatera till den nyare versionen. Mer information finns i 23.1.2 Sista giltighetsdatum för JRE i standardutgåvan av distributionsguiden för Java-plattformen.

Buggfixar

Den här utgåvan innehåller korrigeringar av säkerhetssårbarheter som beskrivs i Oracle Critical Patch Update. En fullständig lista över buggfixar som är inkluderade i den här utgåvan finns i Versionskommentarer till 8u441.

Java 8 uppdatering 431 (8u431)

Viktiga funktioner i versionen

JDK 8u431 innehåller IANA-tidszonsdata för 2024a.
Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Lösta problem: JDK RPM-uppgradering lämnar föräldralöst alternativ post.
Åtgärdat problemet med att poster i grupperna 'java' och 'javac' inte hanterades korrekt under en RPM-uppgradering.
Uppgradering från en äldre Java RPM installerad i en delad katalog (/usr/lib/jvm/jdk-${FEATURE}-oracle-${ARCH})till en Java RPM installerad i en versionsspecifik katalog, (/usr/lib/jvm/jdk-${VERSION}-oracle-${ARCH}), resulterar i att de äldre Java-posterna i grupperna "java"' och "javac"' inte raderas.
JDK-8336107 (inte allmän)
Övriga kommentarer: Nya standardgränser i JDK:s HTTP-implementationer
Standardgränser har lagts till för HTTP i JDK.
Den inbyggda JDK-implementeringen av URL-protokollhanteraren för HTTP (HttpURLConnection) har nu en standardgräns för den maximala storleken på svarshuvuden som accepteras från en fjärransluten part. Gränsen är som standard inställd på 384 kB (393216 byte) och beräknas som den ackumulerade storleken på alla sidhuvudnamn och sidhuvudvärden plus en omkostnad på 32 byte per sidhuvudnamnvärdepar.
JDK-8328286 (inte allmän)
Övriga kommentarer: Lade till SSL.com TLS CA-rotcertifikat utfärdade 2022
Följande rotcertifikat har lagts till i säkerhetslagret cacerts:
+ SSL.com
+ ssltlsrootecc2022
DN: CN=SSL.com TLS ECC Root CA 2022, O=SSL Corporationm, C=US
+ SSL.com
+ ssltlsrootrsa2022
DN: CN=SSL.com TLS RSA Root CA 2022, O=SSL Corporation, C=US
Se JDK-8341057
Övriga kommentarer: Misstänk TLS-servercertifikat som är förankrade med Entrust-rotcertifikat och utfärdade efter den 11 november 2024
JDK kommer att sluta lita på TLS-servercertifikat utfärdade efter den 1 november 2024 och förankrade med Entrust-rotcertifikat, i linje med liknande planer som nyligen meddelats av Google och Mozilla. Listan över berörda certifikat inkluderar certifikat märkta med AffirmTrust, som hanteras av Entrust.
Se JDK-8337664

Hålla JDK uppdaterad

Oracle rekommenderar att JDK uppdateras med varje kritisk programfixuppdatering. Du kan använda sidan Säkerhetsbaslinje för att se vilken version som är den senaste för varje versionsfamilj.

Kritiska programfixuppdateringar som innehåller korrigeringar för säkerhetssårbarheter meddelas ett år i förväg i kritiska programfixuppdateringar, säkerhetsaviseringar och rapporter. Vi rekommenderar inte att den här JDK-versionen (version 8u431) används efter nästa kritiska programfixuppdatering som är schemalagd till den 21 januari 2025.

För system som inte kan nå Oracle-servrarna finns det en sekundär mekanism som upphör i denna JRE (version 8u431) den 16 februari 2024. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av JRE:n om att uppdatera till den nyare versionen. Mer information finns i 23.1.2 Sista giltighetsdatum för JRE i standardutgåvan av distributionsguiden för Java-plattformen.

Buggfixar

Java 8 uppdatering 421 (8u421)

Viktiga funktioner i versionen

JDK8u421 innehåller IANA-tidszonsdata för 2024a.
Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Känt problem: Användning av webbläsarens nyckellager i Windows s
När funktionen "Använd certifikat och nycklar i webbläsarens nyckellager" är aktiverad i Windows (vilket den är som standard) kan Java WebStart och Java Plugin komma åt de certifikat som för närvarande är betrodda av den lokala maskinen. Det finns ingen garanti för att hela listan med betrodda certifikat är tillgänglig, eftersom certifikaten laddas dynamiskt. Som ett resultat kan Java-applets och Java WebStart-applikationer uppleva problem med signaturvalidering och säker anslutning som orsakas av brist på relevanta certifikat eftersom distributionsramverket endast kan komma åt de certifikat som är "aktiva" vid tidpunkten för uppstart av applikationen.
JDK-8330728 (inte offentligt)
Andra anteckningar: Tillägg av STATIC=1-argumentet till JRE-installationsprogrammet
Den här åtgärden lägger tillSTATIC=1-installationsprogramargument och tarRETAIN_ALL_VERSIONS=1 installationsprogramargument ur bruk. Godkännande av STATIC=1 kommer att skydda äldre JRE 8-versioner från att avinstalleras under en manuell uppgradering eller en automatisk uppdatering.
JDK-8313223 (inte offentlig)
Andra anteckningar: Tillagda GlobalSign R46- och E46 Root CA-certifikat
Följande rotcertifikat har lagts till i cacertssäkerhetslagret:
+ GlobalSign + globalsignr46 DN: CN=GlobalSign Root R46, O=GlobalSign nv-sa, C=BE + GlobalSign + globalsigne46 DN: CN=GlobalSign Root E46, O=GlobalSign nv-sa, C=BE
Se JDK-8316138
Andra anteckningar: Installationsprogrammet skapar en knutpunkt på en ny plats
JRE:n installeras på följande plats: C:\Program Files\Java\latest\jre-$fullversion, där "$fullversion" är den tekniska versionen av JRE:n. 8u421 installeras till exempel på C:\Program Files\Java\latest\jre-1.8.0_421.

"C:\Program Files" justeras till "C:\Program Files (x86)" för 32-bitars Java.

En knutpunkt skapas vid C:\Program Files\Java\latest\jre-1.8. Den kommer att peka på den senaste JRE:n för 8-familjen.
JDK-8329700 (inte offentligt)

Hålla JDK uppdaterad

Oracle rekommenderar att JDK uppdateras med varje kritisk programfixuppdatering. Du kan använda sidan Säkerhetsbaslinje för att se vilken version som är den senaste för varje versionsfamilj.

Kritiska programfixuppdateringar som innehåller korrigeringar för säkerhetssårbarheter meddelas ett år i förväg i kritiska programfixuppdateringar, säkerhetsaviseringar och rapporter. Du bör inte använda detta JDK (version 8u421) efter nästa kritiska programfixuppdatering som är schemalagd den 15 oktober 2024.

För system som inte kan nå Oracle-servrarna finns det en sekundär mekanism som upphör i denna JRE (version 8u421) den 15 november 2024. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av JRE:n om att uppdatera till den nyare versionen. Mer information finns i 23.1.2 Sista giltighetsdatum för JRE i standardutgåvan av distributionsguiden för Java-plattformen.

Buggfixar

Java 8 Update 411 (8u411)

Viktiga funktioner i versionen

JDK 8u411 innehåller IANA-tidszonsdata för 2024a.
Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Ny funktion: Tillägg av Certainly R1- och E1-rotcertifikat
Följande rotcertifikat har lagts till i säkerhetslagret för cacerts:+ Certainly + certainlyrootr1 DN: CN=Certainly Root R1, O=Certainly, C=US + Certainly + certainlyroote1 DN: CN=Certainly Root E1, O=Certainly, C=US
Se JDK-8321408
Ny funktion: Aktivering av läget för säker validering av XML-signatur som standard
Läget för säker validering av XML-signatur har aktiverats som standard (det var inte aktiverat som standard tidigare om det inte kördes med en säkerhetshanterare). När det är aktiverat är valideringen av XML-signaturer föremål för striktare kontroller av algoritmer och andra begränsningar enligt inställningarna i säkerhetsegenskapen jdk.xml.dsig.secureValidationPolicy.
Vid behov, och på egen risk, kan applikationer avaktivera läget genom att ange egenskapen org.jcp.xml.dsig.secureValidation som Boolean.FALSE med API:t DOMValidateContext.setProperty().
Se JDK-8259801

Hålla JDK uppdaterad

Oracle rekommenderar att JDK uppdateras med varje kritisk programfixuppdatering. Du kan använda sidan Säkerhetsbaslinje för att se vilken version som är den senaste för varje versionsfamilj.

Kritiska programfixuppdateringar som innehåller korrigeringar för säkerhetssårbarheter meddelas ett år i förväg i kritiska programfixuppdateringar, säkerhetsaviseringar och rapporter. Vi rekommenderar inte att den här JDK-versionen (version 8u411) används efter nästa kritiska programfixuppdatering som är schemalagd till den 16 juli 2024.

För system som inte kan nå Oracle-servrarna finns det en sekundär mekanism som upphör i denna JRE (version 8u411) den 16 augusti 2024. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av JRE:n om att uppdatera till den nyare versionen. Mer information finns i 23.1.2 Sista giltighetsdatum för JRE i standardutgåvan av distributionsguiden för Java-plattformen.

Buggfixar

Java 8 Update 401 (8u401)

Viktiga funktioner i versionen

JDK 8u401 innehåller IANA-tidszonsdata för 2023c.
Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Ny funktion: Ny systemegenskap för växling av läget för säker validering av XML-signaturer
En ny systemegenskap med namnet org.jcp.xml.dsig.secureValidation har lagts till. Den kan användas till att aktivera eller avaktivera läget för säker validering av XML-signaturer. Systemegenskapen ska ställas in på värdet "true" för att aktiveras och på "false" för att avaktiveras. Alla andra värden för systemegenskapen behandlas som falska. Om systemegenskapen har ställts in åsidosätter den egenskapsvärdet XMLCryptoContext. Läget för säker validering är aktiverat som standard om du kör koden med en SecurityManager, annars är det avaktiverat som standard.
Se JDK-8301260
Ny funktion: JDK Flight Recorder-händelse för avserialisering
En ny JDK Flight Recorder-händelse (JFR) har lagts till för att övervaka avserialiseringen av objekt. När JFR är aktiverat och JFR-konfigurationen inkluderar avseriealiseringshändelser utlöser JFR en händelse när programmet som körs försöker avserialisera ett objekt. Avserialiseringshändelsen har namnet java/deserialization och är avaktiverad som standard. Avserialiseringshändelsen innehåller information som används av mekanismen för serialiseringsfilter. Om ett filter är aktiverat anger JFR-händelsen dessutom huruvida filtret accepterat eller avslagit avserialiseringen av objektet.
Se JDK-8261160

Hålla JDK uppdaterad

Oracle rekommenderar att JDK uppdateras med varje kritisk programfixuppdatering. Du kan använda sidan Säkerhetsbaslinje för att se vilken version som är den senaste för varje versionsfamilj.

Kritiska programfixuppdateringar som innehåller korrigeringar för säkerhetssårbarheter meddelas ett år i förväg i kritiska programfixuppdateringar, säkerhetsaviseringar och rapporter. Vi rekommenderar inte att den här JDK-versionen (version 8u401) används efter nästa kritiska programfixuppdatering som är schemalagd till den 16 april 2024.

Kunder med Java SE-prenumerationer som hanterar JRE-uppdateringar/installationer för ett stort antal klientdatorer bör överväga att använda Java Management Service (JMS).

För system som inte kan nå Oracle-servrarna finns det en sekundär mekanism som upphör i denna JRE (version 8u401) den 16 maj 2024. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser från JRE:n om att uppdatera till den senaste versionen. Mer information finns i 23.1.2 Sista giltighetsdatum för JRE i standardutgåvan av distributionsguiden för Java-plattformen.

Buggfixar

Java 8 Update 391 (8u391)

Viktiga funktioner i versionen

JDK 8u391 innehåller IANA-tidszonsdata för 2023c.
Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Ny funktion: Ny JFR-händelse: jdk.SecurityProviderService
En ny JFR-händelse (Java Flight Recorder) har lagts till i postdetaljerna för java.security.Provider.getService(String type, String algorithm)-anrop.
Se JDK-8254711
Borttagen funktion: SECOM Trust Systems rotcertifikat RootCA1 har tagits bort
Det följande rotcertifikatet från SECOM Trust Systems har tagits bort från nyckellagret för cacerts:
+ aliasnamnet "secomscrootca1 [jdk]" Unikt namn: OU=Security Communication RootCA1, O=SECOM Trust.net, C=JP
Se JDK-8295894
Borttagen funktion: Linux ARM32-stöd för JDK 8 har tagits bort
Plattformsstöd för Linux ARM32 i JDK 8 har tagits bort. Det betyder att det inte går att ladda ned ABI av typen Hard Float för ARM32. Operativsystemen som hade stöd för ARM32 har nått sitt livsslut. Det betyder att det inte finns något känt stöd för operativsystemet.
JDK-8305927 (inte allmän)
Övriga anteckningar: Rotcertifikatet Certigna har lagts till
Följande rotcertifikat har lagts till i säkerhetslagret för cacerts:
+ Certigna (Dhimyotis) + certignarootca DN: CN=Certigna Root CA, OU=0002 48146308100036, O=Dhimyotis, C=FR
Se JDK-8314960

Hålla JDK uppdaterad

Oracle rekommenderar att JDK uppdateras med varje kritisk programfixuppdatering. Du kan använda sidan Säkerhetsbaslinje för att se vilken version som är den senaste för varje versionsfamilj.

Kritiska programfixuppdateringar som innehåller korrigeringar för säkerhetssårbarheter meddelas ett år i förväg i kritiska programfixuppdateringar, säkerhetsaviseringar och rapporter. Vi rekommenderar inte att den här JDK-versionen (version 8u391) används efter nästa kritiska programfixuppdatering som är schemalagd till den 16 januari 2024.

Kunder med en Java SE-prenumeration som hanterar JRE-uppdateringar/installationer för ett stort antal klientdatorer bör överväga att använda Java Advanced Management Console (AMC).

För system som inte kan nå Oracle-servrarna finns det en sekundär mekanism som upphör i denna JRE (version 8u391) den 16 februari 2024. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av JRE:n om att uppdatera till den nyare versionen. Mer information finns i 23.1.2 Sista giltighetsdatum för JRE i standardutgåvan av distributionsguiden för Java-plattformen.

Buggfixar

Java 8 Update 381 (8u381)

Viktiga funktioner i versionen

JDK 8u381 innehåller IANA-tidszonsdata för 2023c.
Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Ny funktion: Tillåt fler tecken för GB18030-2022-stöd
CESI (Kinas nationella standardorgan) har nyligen publicerat GB18030-2022, en uppdaterad version av standarden GB18030 som gör GB18030 kompatibel med Unicode version 11.0. Implementeringen av teckenuppsättningen i den här nya standarden har nu ersatt den tidigare 2000-standarden. Den nya standarden har dock några ändringar som inte är kompatibla med den tidigare implementeringen. För alla som behöver använda de gamla mappningarna har vi introducerat en ny systemegenskap, jdk.charset.GB18030. Genom att sätta värdet på den till 2000 används den tidigare JDK-versionens mappningar för teckenuppsättningen GB18030, som baseras på 2000-standarden.
Se JDK-8307229
JDK accepterar nu RSA-nycklar i PKCS#1-format
Nu kan privata och publika RSA-nycklar i PKCS#1-format accepteras av JDK-leverantörer, som RSA KeyFactory.impl från leverantören SunRsaSign. Det privata eller publika RSA-nyckelobjektet ska vara i PKCS#1-format och en kodning som matchar ASN.1-syntaxen för en privat eller publik PKCS#1 RSA-nyckel.
Se JDK-8023980
Övriga kommentarer: Stöd för Cgroup v2 och förbättringar i 8u381
JDK 8u381 innehåller flera förbättringar och korrigeringar som utökar stödet för containrar i cgroup v1 och v2. Några av förbättringarna handlar om att identifiera containrars resursbegränsningar, rapportera samlade containermått, skriva ut ytterligare containerinformation och att förbättra stabiliteten i containerbaserade miljöer.
Se JDK-8307634
Övriga kommentarer: Lade till TWCA CA-rotcertifikat
Följande rotcertifikat har lagts till i säkerhetslagret cacerts:
+ TWCA + twcaglobalrootca DN: CN=TWCA Global Root CA, OU=Root CA, O=TAIWAN-CA, C=TW
Se JDK-8305975
Övriga kommentarer: Lade till 4 GTS CA-rotcertifikat
Följande rotcertifikat har lagts till i säkerhetslagret cacerts:
+ Google Trust Services LLC + gtsrootcar1 DN: CN=GTS Root R1, O=Google Trust Services LLC, C=US + Google Trust Services LLC + gtsrootcar2 DN: CN=GTS Root R2, O=Google Trust Services LLC, C=US + Google Trust Services LLC + gtsrootecccar3 DN: CN=GTS Root R3, O=Google Trust Services LLC, C=US + Google Trust Services LLC + gtsrootecccar4 DN: CN=GTS Root R4, O=Google Trust Services LLC, C=US
Se JDK-8307134
Övriga kommentarer: Lade till Microsoft Corporations 2 TLS CA-rotcertifikat
Följande rotcertifikat har lagts till i säkerhetslagret cacerts:
+ Microsoft Corporation + microsoftecc2017 DN: CN=Microsoft ECC Root Certificate Authority 2017, O=Microsoft Corporation, C=US + Microsoft Corporation + microsoftrsa2017 DN: CN=Microsoft RSA Root Certificate Authority 2017, O=Microsoft Corporation, C=US
Se JDK-8304760

Hålla JDK uppdaterad

Oracle rekommenderar att JDK uppdateras med varje kritisk programfixuppdatering. Du kan använda sidan Säkerhetsbaslinje för att se vilken version som är den senaste för varje versionsfamilj.

Kritiska programfixuppdateringar som innehåller korrigeringar för säkerhetssårbarheter meddelas ett år i förväg i kritiska programfixuppdateringar, säkerhetsaviseringar och rapporter. Du bör inte använda detta JDK (version 8u381) efter nästa kritiska programfixuppdatering som är schemalagd den 17 oktober 2023.

Kunder med en Java SE-prenumeration som hanterar JRE-uppdateringar/installationer för ett stort antal klientdatorer bör överväga att använda Java Advanced Management Console (AMC).

För system som inte kan nå Oracle-servrarna finns det en sekundär mekanism som avaktiverar denna JRE (version 8u381) den 17 november 2023. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av JRE:n om att uppdatera till den nyare versionen. Mer information finns i 23.1.2 Sista giltighetsdatum för JRE i standardutgåvan av distributionsguiden för Java-plattformen.

Buggfixar

Java 8-uppdatering 371 (8u371)

Viktiga funktioner i versionen

JDK 8u371 innehåller IANA-tidszonsdata för 2022g.
Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Ny funktion: Ett inbyggt GSS-API-standardbibliotek har lagts till i Windows
Ett inbyggt GSS-API-bibliotek har lagts till i JDK i Windows-plattformen. Biblioteket finns endast på klientsidan och använder standardinloggningsuppgifter. Det laddas när "true" har angivits för systemegenskapen sun.security.jgss.native. En användare kan fortfarande ladda ett inbyggt GSS-API-bibliotek från en tredje part genom att ange sökvägen i systmegenskapen sun.security.jgss.lib.
Se JDK-6722928
Borttagna funktioner och alternativ: javax.script-motorimplementeringen och com.apple.concurrent.Dispatch har tagits bort från macOS AArch64
AppleScript-motorn som implementerar motor-API:t javax.script har tagits bort utan att ersättas. AppleScript-motorn har fungerat inkonsekvent. Tjänstekonfigurationsfilen (META-INF/services) saknades och fungerade bara av en slump om JDK 7 eller JDK 8 installerades i system som hade Apples version av AppleScriptEngine.jar i systemet.
API:t com.apple.concurrent.Dispatch var ett API endast för Mac. Det fördes vidare till JDK 7u4 med porten för Apples JDK 6-kod. Utvecklare rekommenderas att använda standard-API:erna java.util.concurrent.Executor och java.util.concurrent.ExecutorService i stället.
Se JDK-8297475
Övriga anteckningar: Rotcertifikatet Certigna(Dhimyotis) har lagts till
Följande rotcertifikat har lagts till i säkerhetslagret för cacerts:
+ Certigna (Dhimyotis) + certignarootca DN: CN=Certigna, O=Dhimyotis, C=FR
Se JDK-8245654
Övriga anteckningar: SSLv2Hello och SSLv3 har tagits bort från standardaktiverade TLS-protokoll
SSLv2Hello och SSLv3 har tagits bort från de standardaktiverade TLS-protokollen.

Om SSLv3 tas bort från säkerhetsegenskapen jdk.tls.disabledAlgorithms efter uppdateringen returnerar API:erna SSLSocket.getEnabledProtocols(), SSLServerSocket.getEnabledProtocols(), SSLEngine.getEnabledProtocols() och SSLParameters.getProtocols() "TLSv1.3, TLSv1.2, TLSv1.1, TLSv1". "SSLv3" returneras inte i den här listan.
Om en klient eller server fortfarande behöver använda SSLv3-protokollet kan de göra det om du aktiverar det i systemegenskaperna jdk.tls.client.protocols eller jdk.tls.server.protocols eller med API:erna SSLSocket.setEnabledProtocols(), SSLServerSocket.setEnabledProtocols() och SSLEngine.setEnabledProtocols().
Se JDK-8190492

Hålla JDK uppdaterad

Oracle rekommenderar att JDK uppdateras med varje kritisk programfixuppdatering. Använd sidan Baslinje för säkerhet för att se vilken den senaste versionen för varje utgåvefamilj är.

Kritiska programfixuppdateringar, som innehåller fixar för säkerhetssårbarheter, meddelas ett år i förväg i Kritiska programfixuppdateringar, säkerhetsaviseringar och rapporter. Vi rekommenderar inte att du använder den här JDK-versionen (version 8u371) efter nästa kritiska programfixuppdatering som är schemalagd till den 18 juli 2023.

Kunder med en Java SE-prenumeration som hanterar JRE-uppdateringar/installationer för ett stort antal klientdatorer bör överväga att använda Java Advanced Management Console (AMC).

För system som inte kan nå Oracle-servrarna finns det en sekundär mekanism som upphör i denna JRE (version 8u371) den 18 augusti 2023. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av JRE:n om att uppdatera till den nyare versionen. Mer information finns i 23.1.2 Sista giltighetsdatum för JRE i standardutgåvan av distributionsguiden för Java-plattformen.

Buggfixar

Java 8-uppdatering 361 (8u361)

Viktiga funktioner i versionen

JDK 8u361 innehåller IANA-tidszonsdata för 2022d, 2022e och 2022f.
Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Ny funktion: Stöd för RSASSA-PSS i OCSP-svar
Nu stöds OCSP-svar som signerats med RSASSA-PSS-algoritmen.
Se JDK-8274471
Övriga anteckningar: FXML JavaScript Engine avaktiverad som standard
JavaScripts skriptmotor för FXML har avaktiverats som standard. Alla .fxml-filer som har en Processing Instruction (PI) för "javascript" laddas inte längre som standard och kastar ett undantag.
Den kan aktiveras genom att ange systemegenskapen: -Djavafx.allowjs=true
JDK-8294779 (inte allmän)
Övriga anteckningar: Felaktig hantering av argument omgivna av citattecken i ProcessBuilder
ProcessBuilder i Windows har återställts för att åtgärda en regression orsakad av JDK-8250568. Tidigare överfördes ett argument som började med ett dubbelt citattecken och slutade med ett omvänt snedstreck följt av ett dubbelt citattecken i ProcessBuilder felaktigt till ett kommando och kan orsaka att kommandot inte utförs. Till exempel lästes argumentet "C:\\Program Files\" av kommandot med ett extra par dubbla citattecken. Uppdateringen återställer det äldre beteendet att inte bearbeta ett omvänt snedstreck före ett dubbelt citattecken i slutet.
Se JDK-8282008
Övriga anteckningar: Gör tidsgränsen för den beständiga HTTP-anslutningen HttpURLConnection konfigurerbar som standard
Tillägg av två systemegenskaper som styr beteendet för den beständiga HTTP-anslutningen HttpURLConnection när servern inte specificerar en tid för den beständiga HTTP-anslutningen. Två egenskaper har definierats för att styra anslutningar till servrar och proxyservrar separat. Dessa är http.keepAlive.time.server respektive http.keepAlive.time.proxy. Mer information om dem finns i Nätverksegenskaper.
Se JDK-8278067
Övriga anteckningar:Verktyget VisualVM ingår inte längre
Den här versionen av JDK innehåller inte ett exemplar av Java VisualVM. Nu är VisualVM tillgängligt som en separat nedladdning från https://visualvm.github.io.
Se JDK-8294184

Hålla JDK uppdaterad

Oracle rekommenderar att JDK uppdateras med varje kritisk programfixuppdatering. Du kan använda sidan Säkerhetsbaslinje för att se vilken version som är den senaste för varje versionsfamilj.

Kritiska programfixuppdateringar som innehåller korrigeringar för säkerhetssårbarheter meddelas ett år i förväg i kritiska programfixuppdateringar, säkerhetsaviseringar och rapporter. Vi rekommenderar inte att den här JDK-versionen (version 8u361) används efter nästa kritiska programfixuppdatering som är schemalagd till den 18 april 2023.

Kunder med en Java SE-prenumeration som hanterar JRE-uppdateringar/installationer för ett stort antal klientdatorer bör överväga att använda Java Advanced Management Console (AMC).

För system som inte kan nå Oracle-servrarna finns det en sekundär mekanism som upphör i denna JRE (version 8u361) den 18 maj 2023. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av JRE:n om att uppdatera till den nyare versionen. Mer information finns i 23.1.2 Sista giltighetsdatum för JRE i standardutgåvan av distributionsguiden för Java-plattformen.

Buggfixar

Java 8 Update 351 (8u351)

Viktiga funktioner i versionen

IANA-tidszonsdata för 2022b och 2022c.
Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Övriga anteckningar: Uppgradering av PKCS12-standardalgoritmer för MAC
Standardalgoritmerna för MAC som används i PKCS #12-nyckellagret har uppdaterats. Den nya algoritmen baseras på SHA-256 och är starkare än den gamla som baserades på SHA-1. Se säkerhetsegenskaperna som börjar med keystore.pkcs12 i java.security-filen för mer information.
Se JDK-8267880
Övriga anteckningar: SHA-1-signerade JAR-filer avaktiverade
JAR-filer som har signerats med SHA-1-algoritmer är begränsade som standard och behandlas som osignerade filer. Detta gäller algoritmerna som används för sammandrag, signering och tidsstämpling av JAR-filen vid behov. Det gäller även signatur- och sammandragsalgoritmer i certifikat i certifikatkedjan för kodsigneraren och tidsstämpelbehörigheten samt CRL- eller OCSP-svar som används till att verifiera om certifikaten har återkallats. Begränsningarna gäller även signerade JCE-leverantörer.
Se JDK-8269039
Övriga anteckningar: 3DES och RC4 i Kerberos är tagna ur bruk
Krypteringstyperna (etyper) des3-hmac-sha1 och rc4-hmac i Kerberos har tagits ur bruk och är inaktiva som standard. Användare kan ange allow_weak_crypto = true i konfigurationsfilen krb5.conf för att återaktivera dem (tillsammans med andra svaga etyper inklusive des-cbc-crc och des-cbc-md5) på egen risk. För att avaktivera en delmängd av de svaga etyperna kan användare lista önskade etyper i inställningarna default_tkt_enctypes, default_tgs_enctypes eller permitted_enctypes.
Se JDK-8139348

Hålla JDK uppdaterad

Oracle rekommenderar att JDK uppdateras med varje kritisk programfixuppdatering. Du kan använda sidan Säkerhetsbaslinje för att se vilken version som är den senaste för varje versionsfamilj.

Kritiska programfixuppdateringar som innehåller korrigeringar för säkerhetssårbarheter meddelas ett år i förväg i kritiska programfixuppdateringar, säkerhetsaviseringar och rapporter. Vi rekommenderar inte att den här JDK-versionen (version 8u351) används efter nästa kritiska programfixuppdatering som är schemalagd till den 17 januari 2023.

Kunder med en Java SE-prenumeration som hanterar JRE-uppdateringar/installationer för ett stort antal klientdatorer bör överväga att använda Java Advanced Management Console (AMC).

För system som inte kan nå Oracle-servrarna finns det en sekundär mekanism som upphör i denna JRE (version 8u351) den 17 februari 2023. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av JRE:n om att uppdatera till den nyare versionen. Mer information finns i 23.1.2 Sista giltighetsdatum för JRE i standardutgåvan av distributionsguiden för Java-plattformen.

Buggfixar

Den här utgåvan innehåller korrigeringar av säkerhetssårbarheter som beskrivs i Oracle Critical Patch Update. För en fullständig lista över buggfixar som är inkluderade i den här utgåvan går du till sidan buggfixar i JDK 8u351.

» Versionskommentarer till 8u351

Java 8 Update 341 (8u341)

Viktiga funktioner i versionen

IANA-tidszonsdata för 2022a.
Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Ny funktion: Stöd för HTTPS-kanalbindning för Java GSS/Kerberos
Stöd har lagts till för TLS-token för kanalbindning för Negotiate/Kerberos-autentisering över HTTPS genom javax.net.HttpsURLConnection.

Token för kanalbindning krävs i allt högre grad som en utökad form av säkerhet. De kommunicerar klientens förståelse av bindningen mellan anslutningssäkerhet (som representeras av en TLS-servercertifiering) från en klient till en server och autensieringsuppgifter på högre nivå (så som ett användarnamn och lösenord). Servern kan då upptäcka om klienten har lurats av en MITM och stänga av sessionen/anslutningen.
Se JDK-8279842
Ny funktion: Aktivera TLSv1.3 som standard på JDK 8u för klientroller
Implementeringen av TLSv1.3 är tillgänglig i JDK 8u från 8u261 och är aktiverad som standard för serverroller men inaktiverad som standard för klientroller. Från och med den här versionen är också TLSv1.3 aktiverad som standard för klientroller. Mer information finns i Sektion för ytterligare information i Oracle JRE och JDK Cryptographic Roadmap.
Se JDK-8245263
Övriga anteckningar:Uppdatera java.net.InetAddress för att upptäcka tvetydiga IPv4-adresslitteraler
Klassen för java.net.InetAddress har uppdaterats till att endast acceptera IPv4-adresslitteraler i decimal quad-notation. Klassmetoderna InetAddress är uppdaterade till att kasta en java.net.UnknownHostException för ogiltiga IPv4-adresslitteraler. För att inaktivera denna kontroll kan den nya systemegenskapen "jdk.net.allowAmbiguousIPAddressLiterals" anges som "true".
Se JDK-8277608 (inte allmän)
Övriga anteckningar:Pakettillägg för Java Development Kit kapades vid nedladdning med Firefox 102
På oracle.com och java.com blir vissa pakettillägg för Java Development Kit kapade vid nedladdning med Firefox version 102. De nedladdade paketen har inga filtillägg som ".exe", ".rpm", ".deb". Om du inte kan uppgradera till Firefox ESR 102.0.1 eller Firefox 103 när den släpps, är detta ett sätt att kringgå detta:
‐lägg till ett filtillägg manuellt till filnamnet efter nedladdning.
‐använd en annan webbläsare
Se JDK-8277093

Hålla JDK uppdaterad

Oracle rekommenderar att JDK uppdateras med varje kritisk programfixuppdatering. Du kan använda sidan Säkerhetsbaslinje för att se vilken version som är den senaste för varje versionsfamilj.

Kritiska programfixuppdateringar som innehåller korrigeringar för säkerhetssårbarheter meddelas ett år i förväg i kritiska programfixuppdateringar, säkerhetsaviseringar och rapporter. Det rekommenderas inte att detta JDK (version 8u341) används efter nästa kritiska programfixuppdatering som är schemalagd till den 18 oktober 2022.

Kunder med en Java SE-prenumeration som hanterar JRE-uppdateringar/installationer för ett stort antal klientdatorer bör överväga att använda Java Advanced Management Console (AMC).

För system som inte kan nå Oracle-servrarna finns det en sekundär mekanism som upphör i denna JRE (version 8u341) den 18 november 2022. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av JRE:n om att uppdatera till den nyare versionen. Mer information finns i 23.1.2 Sista giltighetsdatum för JRE i standardutgåvan av distributionsguiden för Java-plattformen.

Buggfixar

» Versionsinformation till 8u341

Java 8 Update 333 (8u333)

Viktiga funktioner i versionen

IANA-tidszonsdata för 2021a.
Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Ändring: Aktivera Windows Alternate Data Streams som standard
Windows-implementeringen av java.io.File har ändrats så att strikta valideringskontroller inte utförs som standard på filsökvägar. Det innebär att kolon (:) är tillåtna i sökvägar på andra platser än direkt efter en enskild enhetsbokstav. Det innebär också att sökvägar som representerar NTFS Alternate Data Streams (ADS) som "filename:streamname" är tillåtna. Detta återställer standardegenskapen för java.io.File tillbaka till vad den var innan CPU-utgåvan som släpptes i april 2022 i vilken strikta valideringskontroller inte utfördes som standard på sökvägar i Windows. Om du vill återaktivera strikta sökvägskontroller i java.io.File ska systemegenskapen jdk.io.File.enableADS anges som false (ignorera skiftläge). Detta kan vara att föredra om till exempel specialenhetssökvägar i Windows som NUL: inte används.
Se JDK-8285445

Hålla JDK uppdaterad

Oracle rekommenderar att JDK uppdateras med varje kritisk programfixuppdatering. Du kan använda sidan Säkerhetsbaslinje för att se vilken version som är den senaste för varje versionsfamilj.

Kritiska programfixuppdateringar som innehåller korrigeringar för säkerhetssårbarheter meddelas ett år i förväg i kritiska programfixuppdateringar, säkerhetsaviseringar och rapporter. Vi rekommenderar inte att den här JDK-versionen (version 8u333) används efter nästa kritiska programfixuppdatering som är schemalagd till den 19 juli 2022.

Kunder med en Java SE-prenumeration som hanterar JRE-uppdateringar/installationer för ett stort antal klientdatorer bör överväga att använda Java Advanced Management Console (AMC).

För system som inte kan nå Oracle-servrarna finns det en sekundär mekanism som upphör i denna JRE (version 8u333) den 19 augusti 2022. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av JRE:n om att uppdatera till den nyare versionen. Mer information finns i 23.1.2 Sista giltighetsdatum för JRE i standardutgåvan av distributionsguiden för Java-plattformen.

Buggfixar

Den här utgåvan är baserad på föregående CPU-utgåva och innehåller inga ytterligare säkerhetskorrigeringar. För en fullständig lista över buggfixar som är inkluderade i den här utgåvan går du till sidan buggfixar i JDK 8u333.

» Versionsinformation till 8u333

Java 8 Update 331 (8u331)

Viktiga funktioner i versionen

IANA-tidszonsdata för 2021e.
Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Ny funktion:Nya XML-bearbetningsgränser
Tre bearbetningsgränser har lagts till. Dessa är:
- jdk.xml.xpathExprGrpLimit
  Beskrivning: Begränsar antalet grupper som ett XPath-uttryck kan innehålla.
  Typ: Heltal
  Värde: Ett positivt heltal. Ett värde som är mindre än eller lika med 0 anger att ingen gräns ska användas. Om värdet inte är ett heltal kastades NumberFormatException. Standard 10.
- jdk.xml.xpathExprOpLimit
  Beskrivning: Begränsar antalet operatorer som ett XPath-uttryck kan innehålla.
  Typ: Heltal
  Värde: Ett positivt heltal. Ett värde som är mindre än eller lika med 0 anger att ingen gräns ska användas. Om värdet inte är ett heltal kastades NumberFormatException. Standard 100.
- jdk.xml.xpathTotalOpLimit
  Beskrivning: Begränsar det totala antalet XPath-operatorer i en XSL-formatmall.
  Typ: Heltal
  Värde: Ett positivt heltal. Ett värde som är mindre än eller lika med 0 anger att ingen gräns ska användas. Om värdet inte är ett heltal kastades NumberFormatException. Standard 10000.
Processorer med stöd
- jdk.xml.xpathExprGrpLimit och jdk.xml.xpathExprOpLimit stöds av XPath-processorn.
- Alla tre gränser stöds av XSLT-processorn.
Ställa in egenskaper
För XSLT-processorn kan egenskaper ändras med TransformerFactory. Till exempel,
```
<code>        TransformerFactory factory = TransformerFactory.newInstance();

        factory.setAttribute("jdk.xml.xpathTotalOpLimit", "1000");
```
För både XPath- och XSLT-processorerna kan egenskaperna ställas in med hjälp av systemegenskapen och konfigurationsfilen jaxp.properties i katalogen conf för Javainstallationen. Till exempel,
```
<code>        System.setProperty("jdk.xml.xpathExprGrpLimit", "20");
```
eller i filen jaxp.properties,
```
<code>        jdk.xml.xpathExprGrpLimit=20
```
JDK-8270504 (inte allmän)
Övriga anteckningar: Visa endast certifikat med korrekta förtroendeinställningar som betrodda certifikatposter i macOS KeychainStore
I macOS visas endast certifikat med korrekta förtroendeinställningar i användarnyckelringen som betrodda certifikatposter i KeychainStore-typen av nyckellagret. Om du anropar metoden KeyStore::setCertificateEntry eller kommandot keytool -importcert i ett KeychainStore-nyckellager utförs de inte med felet KeyStoreException. Anropa istället macOS-kommandot "security add-trusted-cert" för att lägga till ett betrott certifikat i användarnyckelringen.
JDK-8278449 (inte allmän)
Övriga anteckningar: Nu är parsningen av webbadresser i de inbyggda JNDI-leverantörerna LDAP, DNS, RMI och CORBA striktare. Parsningsstyrkan kan hanteras i systemegenskaperna:
Nu är parsningen av webbadresser i de inbyggda JNDI-leverantörerna LDAP, DNS och RMI är striktare. Parsningsstyrkan kan hanteras i systemegenskaperna:
```
<code>  -Dcom.sun.jndi.ldapURLParsing="legacy" | "compat" | "strict" (to control "ldap:" URLs)


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

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

  -Dcom.sun.jndi.corbaURLParsing="legacy" | "compat" | "strict" (to control "iiop:" and "iiopname:" URLs)
```
Standardvärdet är "compat" för alla.
- Läget "legacy" avaktiverar den nya valideringen.
- Läget "compat" begränsar inkompatibiliteter.
- Läget "strict" är striktare och kan orsaka regression genom att avslå webbadresser som en applikation anser är giltiga.
Om en otillåten webbadressträng hittas orsakas ett javax.naming.NamingException (eller ett underklassundantag).
JDK-8278972 (inte allmän)

Hålla JDK uppdaterad

Oracle rekommenderar att JDK uppdateras med varje kritisk programfixuppdatering. Du kan använda sidan Säkerhetsbaslinje för att se vilken version som är den senaste för varje versionsfamilj.

Kritiska programfixuppdateringar som innehåller korrigeringar för säkerhetssårbarheter meddelas ett år i förväg i kritiska programfixuppdateringar, säkerhetsaviseringar och rapporter. Vi rekommenderar inte att den här JDK-versionen (version 8u331) används efter nästa kritiska programfixuppdatering som är schemalagd till den 19 juli 2022.

Kunder med en Java SE-prenumeration som hanterar JRE-uppdateringar/installationer för ett stort antal klientdatorer bör överväga att använda Java Advanced Management Console (AMC).

För system som inte kan nå Oracle-servrarna finns det en sekundär mekanism som upphör i denna JRE (version 8u331) den 19 augusti 2022. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av JRE:n om att uppdatera till den nyare versionen. Mer information finns i 23.1.2 Sista giltighetsdatum för JRE i standardutgåvan av distributionsguiden för Java-plattformen.

Buggfixar

» Versionsinformation till 8u331

Java 8 Update 321 (8u321)

Viktiga funktioner i versionen

IANA TZ-data 2021b, 2021c, 2021d, 2021e.
JDK 8u321 innehåller IANA-tidszonsdata för 2021b, 2021c, 2021d, 2021e. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Ny funktion: Nya konfigurationsegenskaper för SunPKCS11
Leverantören av SunPKCS11 har lagt till nya attribut för leverantörskonfiguration av att kontrollera användningen av inbyggda resurser på ett bättre sätt. Leverantören av SunPKCS11 använder inbyggda resurser för att fungera med inbyggda PKCS11-bibliotek. Ytterligare konfigurationsattribut läggs till för att hantera och kontrollera de inbyggda resurserna på ett bättre sätt. Detta kontrollerar frekvensen av att rensa inbyggda referenser samt om underliggande PKCS11-token ska förstöras efter utloggning.
Se JDK-8240256
Borttagna funktioner och alternativ: Rotcertifikatet för Googles GlobalSign har tagits bort
Följande rotcertifikat från Google har tagits bort från nyckellagret cacerts:
+ alias name "globalsignr2ca [jdk]" Unikt namn: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2
Se JDK-8225083
Övriga anteckningar: Uppdatering av tidszonsdata i 2021c
Några finjusteringar av tidszonsregler har tillkommit sedan 2021c i databasen för IANA-tidszonsdata, i vilken JDK:s bibliotek för tid och datum är baserad. Efter uppdateringen har dock en del av tidszonsreglerna som skapades före 1970 justerats i enlighet med ändringarna som introducerades i 2021b. Mer information finns i upplysningen om 2021b
Se JDK-8274407

Hålla JDK uppdaterad

Oracle rekommenderar att JDK uppdateras med varje kritisk programfixuppdatering. Du kan använda sidan Säkerhetsbaslinje för att se vilken version som är den senaste för varje versionsfamilj.

Kritiska programfixuppdateringar, som innehåller fixar för säkerhetssårbarheter, meddelas ett år i förväg i Kritiska programfixuppdateringar, säkerhetsaviseringar och rapporter. Vi rekommenderar inte att den här JDK-versionen (version 8u291) används efter nästa kritiska programfixuppdatering som är schemalagd till den 20 juli 2021.

Kunder med en Java SE-prenumeration som hanterar JRE-uppdateringar/installationer för ett stort antal klientdatorer bör överväga att använda Java Advanced Management Console (AMC).

För system som inte kan nå Oracle-servrarna finns det en sekundär mekanism som upphör i denna JRE (version 8u291) den 20 augusti 2021. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av JRE:n om att uppdatera till den nyare versionen. Mer information finns i 23.1.2 Sista giltighetsdatum för JRE i standardutgåvan av distributionsguiden för Java-plattformen.

Buggfixar

» Versionsinformation till 8u321

Java 8 Update 311 (8u311)

Viktiga funktioner i versionen

IANA TZ-data 2021a.
Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Ny funktion: Marlin-renderaren i JDK 8u
Från och med version 8u311 utformas och distribueras grafikrastreraren Marlin och dess artefakter som en del av JDK/JRE-paketen. Det är inte standardmotorn för rendering, men det finns ett alternativ för att aktivera den genom att ange följande systemegenskap:
sun.java2d.renderer=sun.java2d.marlin.MarlinRenderingEngine
Se JDK-8143849
Ny funktion:Kontextspecifik delmängd för avserialiseringsfilter
Tillåt applikationer att konfigurera kontextspecifika och dynamiskt markerade avserialiseringsfilter via en JVM-filterfabrik som anropas för att markera ett filter för varje avserialiseringsström. Funktionen är en strikt delmängd av JEP 415: Kontextspecifika avserialiseringsfilter för att tillåta att en filterfabrik blir konfigurerad genom att använda en egenskap som har konfigurerats i kommandoraden eller i filen för säkerhetsegenskaper.
Mer information finns i Kontextspecifika avserialiseringsfilter ochGuide till serialiseringsfiltrering.
JDK-8268680 (inte allmän)
Borttagna funktioner och alternativ: Tagit bort rotcertifikatet för IdenTrust
Följande rotcertifikat från IdenTrust har tagits bort från nyckellagrets cacerts:
+ alias name "identrustdstx3 [jdk]"
Distinguished Name: CN=DST Root CA X3, O=Digital Signature Trust Co.
See JDK-8225082
Övriga kommentarer: Utgåvan erkänner inte Windows 11 på korrekt sätt
Den här utgåvan identifierar inte Windows 11 på korrekt sätt. Egenskapen os.name är inställd på Windows 10 på Windows 11. I HotSpot-felloggar identifieras operativsystemet som Windows 10, men HotSpot-felloggen visar byggesnumret. Windows 11 har Build 22000.194 eller högre.
Se JDK-8274840
Övriga anteckningar: Uppdaterat den standardaktiverade inställningen för krypteringssviter
Krypteringssvitens standardprioritetsordning för TLS 1.0 till TLS 1.3 har justerats.
För TLS 1.3 är TLS_AES_256_GCM_SHA384 nu prioriterad över TLS_AES_128_GCM_SHA256.
För TLS 1.0 till TLS 1.2 har några av de mellanliggande sviterna nedprioriterats enligt följande:
- Krypteringssviter som inte bevarar framåtsekretess har flyttats längre ned i prioritet jämfört med dem som stöder framåtsekretess.
- Krypteringssviter som använder SHA-1 har nedprioriterats.
Se JDK-8163326
Övriga kommentarer: Ändrad HttpURLConnection-funktion när en lämplig proxy inte hittas
Funktionen för HttpURLConnection vid användning av ProxySelector har ändrats i den här JDK-utgåvan. HttpURLConnection används till att återgå till ett direktanslutningsförsök om den konfigurerade proxyn eller de konfigurerade proxyservrarna inte kan ansluta. Från och med den här utgåvan har standardfunktionen ändrats till att inte längre använda en direktanslutning när det första proxyanslutningsförsöket inte utförs.
Se JDK-8161016

Hålla JDK uppdaterad

Oracle rekommenderar att JDK uppdateras med varje kritisk programfixuppdatering. Du kan använda sidan Säkerhetsbaslinje för att se vilken version som är den senaste för varje versionsfamilj.

Kritiska programfixuppdateringar som innehåller korrigeringar för säkerhetssårbarheter meddelas ett år i förväg i kritiska programfixuppdateringar, säkerhetsaviseringar och rapporter. Vi rekommenderar inte att den här JDK-versionen (version 8u311) används efter nästa kritiska programfixuppdatering som är schemalagd till den 18 januari 2022.

Kunder med en Java SE-prenumeration som hanterar JRE-uppdateringar/installationer för ett stort antal klientdatorer bör överväga att använda Java Advanced Management Console (AMC).

För system som inte kan nå Oracle-servrarna finns det en sekundär mekanism som upphör i denna JRE (version 8u311) den 18 februari 2022. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av JRE:n om att uppdatera till den nyare versionen. Mer information finns i 23.1.2 Sista giltighetsdatum för JRE i standardutgåvan av distributionsguiden för Java-plattformen.

Buggfixar

Den här utgåvan innehåller korrigeringar av säkerhetssårbarheter som beskrivs i Oracle Critical Patch Update. För en fullständig lista över buggkorrigeringar som är inkluderade i den här utgåvan går du till sidan för buggkorrigeringar i JDK 8u311.

» Versionsinformation till 8u311

Java 8 Update 301 (8u301)

Viktiga funktioner i versionen

IANA TZ-data 2021a.
JDK 8u301 innehåller IANA tidzonsdata för 2021a. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Ny funktion: Anpassning av PKCS12-nyckellagergeneration
Nya system- och säkerhetsegenskaper har lagts till för att låta användare anpassa genereringen av PKCS #12-nyckellager. Detta inkluderar algoritmer och parametrar för nyckelskydd, certifikatskydd och MacData. En detaljerad förklaring och möjliga värden för dessa egenskaper kan hittas i "PKCS12-nyckellageregenskaper" i avsnittet java.security file.
Se JDK-8076190
Borttagna funktioner och alternativ: Tagit bort rotcertifikat med nycklar på 1024 bit
Rotcertifikat med öppna nycklar på 1024 bit för RAS har tagits bort från nyckellagrets cacerts.
Se JDK-8243559
Borttagna funktioner och alternativ: Borttagning av Telia-företagets Sonera Class2 CA-certifikat
Följande rotcertifikat har tagits bort från säkerhetslagrets cacerts:
+ Telia Company + soneraclass2ca DN: CN=Sonera Class2 CA, O=Sonera, C=FI
Se JDK-8225081
Andra anteckningar: Uppgradering av PKCS12-standardkrypteringsalgoritmer
Standardkrypteringsalgoritmerna som används i PKCS #12-nyckellagret har uppdaterats. De nya algoritmerna baseras på AES-256 och SHA-256 och är starkare en de gamla algoritmerna som baserades på RC2, DESede, och SHA-1. Se säkerhetsegenskaperna som börjar med keystore.pkcs12 i java.security-filen för mer information.
För kompatibilitet har en ny systemegenskap med namnetkeystore.pkcs12.legacy definierats för att återställa algoritmerna för att använda de gamla, svagare algoritmerna. Det finns inget definierat värde för den här egenskapen.
Se JDK-8153005

Hålla JDK uppdaterad

Oracle rekommenderar att JDK uppdateras med varje kritisk programfixuppdatering. Du kan använda sidan Säkerhetsbaslinje för att se vilken version som är den senaste för varje versionsfamilj.

Kritiska programfixuppdateringar, som innehåller fixar för säkerhetssårbarheter, meddelas ett år i förväg i Kritiska programfixuppdateringar, säkerhetsaviseringar och rapporter. Vi rekommenderar inte att detta JDK (version 8u301) används efter nästa kritiska programfixuppdatering som är schemalagd till den 19 oktober 2021.

Kunder med en Java SE-prenumeration som hanterar JRE-uppdateringar/installationer för ett stort antal klientdatorer bör överväga att använda Java Advanced Management Console (AMC).

För system som inte kan nå Oracle-servrarna finns det en sekundär mekanism som upphör i denna JRE (version 8u301) den 19 november 2021. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av JRE:n om att uppdatera till den nyare versionen. Mer information finns i 23.1.2 Sista giltighetsdatum för JRE i standardutgåvan av distributionsguiden för Java-plattformen.

Buggfixar

» Versionsinformation till 8u301

Java 8 Update 291 (8u291)

Viktiga funktioner i versionen

IANA TZ-data 2020e, 2020f, 2021a.
JDK 8u291 innehåller IANA-tidszonsdata 2020e, 2020f, 2021a. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Övriga anteckningar: Nya system- och säkerhetsegenskaper som styr fjärrobjektsrekonstruktionen av JDK:s inbyggda JNDI RMI- och LDAP-implementeringar
jdk.jndi.object.factoriesFilter: System- och säkerhetsegenskapen tillåter att ett seriellt filter kan anges för att styra uppsättningen av objektfabriksklasser som har behörighet att instansiera objekt från objektreferenser som har returnerats av namngivnings-/katalogsystem. Fabriksklassen som har namngetts av referensinstansen matchas mot filtret vid fjärreferensrekonstruktionen. Filteregenskapen stöder mönsterbaserad filtersyntax med ett format som anges av JEP 290. Egenskapen omfattar de inbyggda JNDI/RMI- och JNDI/LDAP-leverantörsimplementeringarna. Standardvärdet tillåter alla objektfabriksklasser som anges i referensen för att återskapa det refererade objektet.
JDK-8244473 (inte allmän)
Övriga anteckningar: Standardversionen av Java har inte uppdaterats för att Javaarkivet ska kunna exekveras med ett dubbelklick
Om PATH-miljövariabeln innehåller en post som har konfigurerats av Oracle JDK-installationsprogram från nyare utgåvor infogar Oracle JRE-installationsprogrammet sökvägen till katalogen som innehåller Javakommandona (java.exe, javaw.exe och javaws.exe) i PATH-miljövariabeln efter posten. Tidigare ignorerade Oracle JRE-installationsprogrammet ändringar som gjordes i PATH-miljövariabeln av Oracle JDK-installationsprogram från nyare utgåvor och gjorde felaktiga uppdateringar av värdet för PATH-miljövariabeln. Se följande CSR för mer teknisk information: https://bugs.openjdk.java.net/browse/JDK-8259858
Se JDK-8259215
Övriga anteckningar: Avaktivera TLS 1.0 och 1.1
TLS 1.0 och 1.1 är versioner av TLS-protokollet som inte längre anses vara säkra och har ersatts med säkrare och modernare versioner (TLS 1.2 och 1.3).
Nu är dessa versioner avaktiverade som standard. Om du stöter på problem kan du på egen risk återaktivera versionerna genom att ta bort "TLSv1" och/eller "TLSv1.1" från säkerhetsegenskapen jdk.tls.disabledAlgorithms i konfigurationsfilen java.security.
Se JDK-8202343
Övriga anteckningar: Avaktivera TLS 1.0 och 1.1 för Javainsticksappletar och Java Web Start-applikationer
TLS 1.0 och 1.1 har avaktiverats. Dessa protokoll används INTE av Javainsticksappletar och Java Web Start-applikationer som standard. Om du stöter på problem kan du återaktivera protokollen via kontrollpanelen för Java.
JDK-8255892 (inte allmän)

Hålla JDK uppdaterad

Oracle rekommenderar att JDK uppdateras med varje kritisk programfixuppdatering. Du kan använda sidan Säkerhetsbaslinje för att se vilken version som är den senaste för varje versionsfamilj.

Kritiska programfixuppdateringar, som innehåller fixar för säkerhetssårbarheter, meddelas ett år i förväg i Kritiska programfixuppdateringar, säkerhetsaviseringar och rapporter. Vi rekommenderar inte att den här JDK-versionen (version 8u291) används efter nästa kritiska programfixuppdatering som är schemalagd till den 20 juli 2021.

Kunder med en Java SE-prenumeration som hanterar JRE-uppdateringar/installationer för ett stort antal klientdatorer bör överväga att använda Java Advanced Management Console (AMC).

Buggfixar

» Versionsinformation till 8u291

Java 8 Update 281 (8u281)

Viktiga funktioner i versionen

IANA-data 2020d
JDK 8u281 innehåller IANA-tidszonsdata version 2020d. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Ny funktion: Alternativ för groupname har lagts till vid generering av nyckelpar för nyckelverktyg
Ett nytt alternativ för -groupname har lagts till för keytool -genkeypair så att användaren kan ange en namngiven grupp vid generering av ett nyckelpar. Till exempel genererar keytool -genkeypair -keyalg EC -groupname secp384r1 ett nyckelpar för e-handel med hjälp av kurvan secp384r1. I och med att det kan finnas flera kurvor med samma storlek rekommenderas du att använda alternativet -groupname framför alternativet -keysize.
Se JDK-8213400
Ny funktion: Apache Santuario-biblioteket har uppdaterats till version 2.1.4
Apache Santuario-biblioteket har uppgraderats till version 2.1.4. Därför har den nya systemegenskapen com.sun.org.apache.xml.internal.security.parser.pool-size lagts till.
Den nya systemegenskapen anger poolstorleken för den interna cachen för DocumentBuilder som används vid bearbetning av XML-signaturer. Funktionen motsvarar systemegenskapen org.apache.xml.security.parser.pool-size som används i Apache Santuario och har samma standardvärde på 20.
Se JDK-8231507
Ny funktion: Stöd för tillägget certificate_authorities
Tillägget certificate_authorities är ett valfritt tillägg som lades till i TLS 1.3. Det används till att ange de certifikatutfärdare som en slutpunkt stöder och ska användas av den mottagande slutpunkten som vägledning vid certifikaturval.
Se JDK-8206925
Övriga anteckningar: Properties.loadFromXML har ändrats för att stämma med specifikationerna
Implementering av metoden java.util.Properties loadFromXML har ändrats för att stämma med dess specifikationer. Mer specifikt avslår den underliggande XML-parserimplementeringen nu icke-kompatibla XML-dokument genom att kasta ett InvalidPropertiesFormatException enligt vad som anges för metoden loadFromXML.
Se JDK-8213325
Övriga anteckningar: Zonnamnet US/Pacific-New har tagits bort som en del av tzdata2020b
Efter uppdateringen av JDK till tzdata2020b har de sedan länge utgångna filerna med namnen pacificnew och systemv tagits bort. Därför kan zonnamnet US/Pacific-New som deklareras i datafilen pacificnew inte lägre användas.
Se JDK-8254177

Hålla JDK uppdaterad

Oracle rekommenderar att JDK uppdateras med varje kritisk programfixuppdatering. Du kan använda sidan Säkerhetsbaslinje för att se vilken version som är den senaste för varje versionsfamilj.

Kritiska programfixuppdateringar, som innehåller fixar för säkerhetssårbarheter, meddelas ett år i förväg i Kritiska programfixuppdateringar, säkerhetsaviseringar och rapporter. Vi rekommenderar inte att den här JDK-versionen (version 8u281) används efter nästa kritiska programfixuppdatering som är schemalagd till den 20 april 2021.

Kunder med en Java SE-prenumeration som hanterar JRE-uppdateringar/installationer för ett stort antal klientdatorer bör överväga att använda Java Advanced Management Console (AMC).

För system som inte kan nå Oracles servrar avaktiverar en sekundär mekanism den här JRE-versionen (version 8u281) den 15 maj 2021. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av JRE:n om att uppdatera till den nyare versionen. Mer information finns i 23.1.2 Sista giltighetsdatum för JRE i standardutgåvan av distributionsguiden för Java-plattformen.

Buggfixar

Den här utgåvan innehåller korrigeringar av säkerhetssårbarheter som beskrivs i Oracle Critical Patch Update. Du hittar en fullständig lista över buggfixar som är inkluderade i den här utgåvan på sidan Buggfixar i JDK 8u281.

» Versionsinformation till 8u281

Java 8 Update 271 (8u271)

Viktiga funktioner i versionen

IANA-data 2020a
JDK 8u271 innehåller version 2020a av IANA-tidszonsdata. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Ny funktion: Svaga namngivna kurvor i TLS, CertPath och signerade javaarkiv är avaktiverade som standard
Svaga namngivna kurvor avaktiveras som standard genom att de läggs till bland följande säkerhetsegenskaper för disabledAlgorithms: jdk.tls.disabledAlgorithms, jdk.certpath.disabledAlgorithms och jdk.jar.disabledAlgorithms. Det finns 47 svaga namngivna kurvor som ska avaktiveras och det skulle innebära ett enormt arbete att lägga till de namngivna kurvorna var för sig till varje egenskap för disabledAlgorithms. Det här förenklas genom att en ny säkerhetsegenskap, jdk.disabled.namedCurves, används vilken kan lista de namngivna kurvor som är gemensamma för alla egenskaper för disabledAlgorithms. Om du vill använda den nya egenskapen bland egenskaperna för disabledAlgorithms sätter du nyckelordet include före det fullständiga egenskapsnamnet. Användarna kan fortfarande lägga till enstaka namngivna kurvor bland egenskaperna för disabledAlgorithms separat från denna nya egenskap. Inga andra egenskaper kan läggas till bland egenskaperna för disabledAlgorithms.
Se JDK-8233228
Ny funktion: Stöd för Kerberos-korssfärshänvisningar (RFC 6806)
Kerberos-klienten har förbättrats med stöd för standardisering av huvudnamn och korssfärshänvisningar, enligt definitionen i tillägget till RFC 6806-protokollet.
Tack vare den här nya funktionen kan Kerberos-klienten dra nytta av mer dynamiska miljökonfigurationer och behöver inte nödvändigtvis veta (i förväg) hur målhuvudets (användaren eller tjänstens) sfär ska nås.
Se JDK-8223172
Borttagen funktion: Java-insticksprogrammet har tagits bort från JDK 8u för Linux-, Solaris- och MacOS-plattformar
NPAPI anses vara ett sårbart insticksprogram och har avaktiverats i många webbläsare. Inga webbläsare har för närvarande stöd för Java-insticksprogrammet, som är NPAPI-baserat, på Linux-, Solaris och MacOS-plattformar.
Från och med 8u271 byggs inte den del av Java-insticksprogrammet som ansvarar för integrering och interaktion med en webbläsare (särskilt libnpjp2-bibliotek) och en associerad artefakt och ingår inte i JRE-distributionen på Linux-, Solaris- och MacOS-plattformar.
JDK-8240210 (inte allmän)
Övriga anteckningar: Ny egenskap för att styra LDAP-autentiseringsmekanismer som tillåts autentisera över Clear-anslutningar
En ny miljöegenskap, jdk.jndi.ldap.mechsAllowedToSendCredentials, har lagts till för att styra vilka LDAP-autentiseringsmekanismer som tillåts för att skicka inloggningsuppgifter via clear-LDAP-anslutningar - anslutningar som inte skyddas med TLS. En krypterad LDAP-anslutning är en anslutning som öppnas vid användning av ldaps-schema, eller en anslutning som öppnas vid användning av ldap-schema och sedan uppgraderas till TLS med en utökad STARTTLS-åtgärd.
JDK-8237990 (inte allmän)

Hålla JDK uppdaterad

Oracle rekommenderar att JDK uppdateras med varje kritisk programfixuppdatering. Använd följande sida för säkerhetsbaslinjen för att se vilken version som är den senaste för varje versionsfamilj.

Kritiska programfixuppdateringar, som innehåller fixar för säkerhetssårbarheter, meddelas ett år i förväg i Kritiska programfixuppdateringar, säkerhetsaviseringar och rapporter. Vi rekommenderar inte att den här JDK-versionen (version 8u271) används efter nästa kritiska programfixuppdatering som är schemalagd till den 19 januari 2021.

Kunder med en Java SE-prenumeration som hanterar JRE-uppdateringar/installationer för ett stort antal klientdatorer bör överväga att använda Java Advanced Management Console (AMC).

För system som inte kan nå Oracle-servrarna finns det en sekundär mekanism som upphör i denna JRE (version 8u271) den 20 februari 2021. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av JRE:n om att uppdatera till den nyare versionen. Mer information finns i 23.1.2 Sista giltighetsdatum för JRE i standardutgåvan av distributionsguiden för Java-plattformen.

Buggfixar

Den här utgåvan innehåller korrigeringar av säkerhetssårbarheter som beskrivs i Oracle Critical Patch Update. En fullständig lista med buggfixar som är inkluderade i den här utgåvan finns på sidan med buggfixar i JDK 8u271.

» Versionsinformation för 8u271

Java 8 Update 261 (8u261)

Viktiga funktioner i versionen

IANA-data 2020a
JDK 8u261 innehåller IANA-tidszonsdata version 2020a. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Ny funktion: Förändringar som rör JDK/JRE-beroendet av Windows Visual Studio Library (DLL) för exekvering
Som en del av det pågående underhållet ska verktygskedjan i Microsoft Visual Studio 2017 användas för att bygga JDK 7 och JDK 8 för Windows. JDK 8u261, i CPU:n från juli 2020, byggdes med Visual Studio 2017. I och med CPU-versionen i oktober 2020 flyttas JDK 7u281 över till Visual Studio 2017.
JDK-8246783 (inte allmän)
Ny funktion: JEP 332 Transport Layer Security (TLS) 1.3
JDK 8u261 inkluderar en implementering av specifikationen Transport Layer Security (TLS) 1.3 (RFC 8446). För närmare information, inklusive en lista över de funktioner som stöds, se referensguidedokumentationen till Java Secure Socket Extension (JSSE) och JEP 332.
Se JDK-814252
Ny funktion: Nya systemegenskaper för att konfigurera TLS-signaturscheman
Två nya systemegenskaper har lagts till för att anpassa TLS-signaturscheman i JDK.
jdk.tls.client.SignatureSchemes har lagts till för TLS-klientsidan och jdk.tls.server.SignatureSchemes har lagts till för serversidan.
Se JDK-8242141
Ny funktion: Förhandlade FFDHE-parametrar (Finite Field Diffie-Hellman Ephemeral) för TLS
Implementationen av JDK:t SunJSSE stöder nu FFDHE-mekanismer för TLS enligt definitionen i RFC 7919. Om en server inte kan bearbeta TLS-tillägget supported_groups eller de namngivna grupperna i tillägget så kan applikationer anpassa de gruppnamn som stöds med jdk.tls.namedGroups eller avaktivera FFDHE-mekanismerna genom att ange "false" för systemegenskapen jsse.enableFFDHE.
Se JDK-8140436

Hålla JDK uppdaterad

Kritiska programfixuppdateringar, som innehåller fixar för säkerhetssårbarheter, meddelas ett år i förväg i Kritiska programfixuppdateringar, säkerhetsaviseringar och rapporter. Vi rekommenderar inte att detta JDK (version 8u261) används efter nästa kritiska programfixuppdatering som är schemalagd till den 13 oktober 2020.

Kunder med en Java SE-prenumeration som hanterar JRE-uppdateringar/installationer för ett stort antal klientdatorer bör överväga att använda Java Advanced Management Console (AMC).

För system som inte kan nå Oracles servrar upphör en sekundär mekanism den här JRE-versionen (version 8u261) den 13 november 2020. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av JRE:n om att uppdatera till den nyare versionen. Mer information finns i 23.1.2 Sista giltighetsdatum för JRE i standardutgåvan av distributionsguiden för Java-plattformen.

Buggfixar

Den här utgåvan innehåller korrigeringar av säkerhetssårbarheter som beskrivs i Oracle Critical Patch Update. För en lista över de buggfixar som är inkluderade i den här utgåvan går du till sidan med buggfixar i JDK 8u261.

» Versionsinformation till 8u261

Java 8 Update 251 (8u251)

Viktiga funktioner i versionen

IANA-data 2019c
JDK 8u251 innehåller IANA-tidszonsdata version 2019c. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Ny funktion: Ytterligare stöd för PKCS#1 v2.2-algoritmer inklusive RSASSA-PSS-signaturer
Leverantörerna av SunRsaSign och SunJCE har förstärkts med stöd för fler algoritmer definierade i PKCS#1 v2.2 som RSASSA-PSS-signaturer och OAEP med FIPS 180-4-sammandragsalgoritmer. Nya konstruktorer och metoder har lagts till i relevanta JCA/JCE-klasser i paketen java.security.spec och javax.crypto.spec som stöd för fler RSASSA-PSS-parametrar.
Se JDK-8146293
Övriga anteckningar: WebEngine-begränsningar för JavaScript-metoder anropar särskilda klasser
JavaScript-program som körs i en webbsidekontext och som laddas av WebEngine kan kommunicera med Java-objekt som överförs från applikationen till JavaScript-programmet. JavaScript-program som refererar till java.lang.Class-objekt begränsas nu till följande metoder:
getCanonicalName getEnumConstants getFields getMethods getName getPackageName getSimpleName getSuperclass getTypeName getTypeParameters isAssignableFrom isArray isEnum isInstance isInterface isLocalClass isMemberClass isPrimitive isSynthetic toGenericString toString

Inga metoder kan anropas med följande klasser:
java.lang.ClassLoader java.lang.Module java.lang.Runtime java.lang.System java.lang.invoke.* java.lang.module.* java.lang.reflect.* java.security.* sun.misc.*

JDK-8236798 (inte allmän)
Övriga anteckningar: Nya Oracle-specifika JDK 8 uppdaterar systemegenskaper till Base64-kodningsformat som är reserver eller äldre
Oracle JDK 8u231 uppgraderade biblioteken i Apache Santuario till v2.1.3. Uppgraderingen införde ett fel som gjorde att &#xd eller &#13 lades till i slutet av de kodade utdata om XML-signaturer med Base64-kodning användes. Ändringen i beteendet gjordes i kodbasen för Apache Santuario för att överensstämma med RFC 2045. Santuario-teamet ska från och med nu se till att biblioteken överensstämmer med RFC 2045.
Se JDK-8236645

Hålla JDK uppdaterad

Kritiska programfixuppdateringar, som innehåller fixar för säkerhetssårbarheter, meddelas ett år i förväg i Kritiska programfixuppdateringar, säkerhetsaviseringar och rapporter. Vi rekommenderar inte att den här JDK-versionen (version 8u251) används efter nästa kritiska programfixuppdatering som är schemalagd till den 14 juli 2020.

För system som inte kan nå Oracle-servrarna finns det en sekundär mekanism som får den här JRE-versionen (version 8u251) att upphöra den 14 augusti 2020. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av JRE:n om att uppdatera till den nyare versionen. Mer information finns i 23.1.2 Sista giltighetsdatum för JRE i standardutgåvan av distributionsguiden för Java-plattformen.

Buggfixar

Den här utgåvan innehåller korrigeringar av säkerhetssårbarheter som beskrivs i Oracle Critical Patch Update. För en lista över buggfixar som är inkluderade i den här utgåvan går du till sidan med buggfixar i JDK 8u251.

» Versionskommentarer till 8u251

Java 8 Update 241 (8u241)

Viktiga funktioner i versionen

IANA-data 2019c
JDK 8u241 innehåller IANA-tidszonsdata version 2019c. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Ny funktion: Tillåt begränsade SASL-mekanismer
En säkerhetsegenskap med namnet jdk.sasl.disabledMechanisms har lagts till och kan användas till att avaktivera SASL-mekanismer. Alla avaktiverade mekanismer ignoreras om de anges i argumentet mechanisms i Sasl.createSaslClient eller argumentet mechanism i Sasl.createSaslServer. Standardvärdet för säkerhetsegenskapen är tom, vilket betyder att inga mekanismer är avaktiverade som standard.
Se JDK-8200400
Ny funktion: Leverantören SunPKCS11 har uppdaterats med stöd för PKCS#11 v2.40
Leverantören SunPKCS11 har uppdaterats med stöd för PKCS#11 v2.40. Versionen lägger till stöd för fler algoritmer som chiffret AES/GCM/NoPadding, DSA-signaturer med en SHA-2-familj av meddelandekondensat och RSASSA-PSS-signaturer när motsvarande PKCS11-mekanismer stöds av det underliggande PKCS11-biblioteket.
Se JDK-8080462
Övriga anteckningar: Nya kontroller av certifikat för förtroendeankare
Nya kontroller har lagts till för att säkerställa att förtroendeankare är CA-certifikat och innehåller rätt tillägg. Förtroendeankare används till att validera certifikatkedjor som används i TLS och signerad kod. Certifikat med förtroendeankare måste innehålla ett tillägg för grundläggande begränsningar med fältet cA inställt på sant. Om de innehåller ett tillägg för nyckelanvändning måste även biten keyCertSign vara angiven.
JDK-8230318 (inte allmän)
Övriga anteckningar: Exakt matchning krävs för betrodda TLS-servercertifikat
Ett TLS-servercertifikat måste vara en exakt matchning av ett betrott certifikat på klienten för att det ska vara betrott när en TLS-anslutning upprättas.
JDK-8227758 (inte allmän)
Övriga anteckningar: Det nya certifikatet LuxTrust Global Root 2 har lagts till
Rotcertifikatet LuxTrust har lagts till i cacertssäkerhetslagret
Se JDK-8232019
Övriga anteckningar: Certifikatet 4 Amazon Root CA har lagts till
Rotcertifikatet Amazon har lagts till i cacertssäkerhetslagret
Se JDK-8233223
Buggfixar: Stöd för teckensnitt i OpenType CFF
Tidigare inkluderade Oracle JDK 8 inte teckensnitt i OpenType CFF (.otf-teckensnitt) i de logiska standardteckensnitten (t.ex. Dialog och SansSerif). Detta resulterade i att glyfer saknades i återgiven text. Ett Java-undantag kunde kastas i de mest extrema fallen när endast CFF-teckensnitt hade installerats på systemet.
Flera Linux-distributioner påverkades av problemet eftersom de använde CFF-teckensnitt för att stödja en del språk, ofta CJK-språk (kinesiska, japanska och koreanska).
Nu använder Oracle JDK 8 CFF-teckensnitten, vilket har löst problemet.
Se JDK-8209672
Buggfixar: Förbättrad hantering av seriella filter
Systemegenskapen jdk.serialFilter kan endast anges på kommandoraden. Om filtret inte har angetts på kommandoraden kan det anges med java.io.ObjectInputFilter.Config.setSerialFilter. Det går inte att ange jdk.serialFilter med java.lang.System.setProperty.
JDK-8231422 (inte allmän)

Utgångsdatum för Java

Utgångsdatumet för 8u241 är 14 april 2020. Java går ut när en ny utgåva med korrigeringar av säkerhetsrisker blir tillgänglig. För system som inte kan nå Oracles servrar avaktiverar en sekundär mekanism den här JRE-versionen (version 8u241) den 14 maj 2020. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av JRE:n om att uppdatera till den nyare versionen.

Buggfixar

Den här utgåvan innehåller korrigeringar av säkerhetssårbarheter som beskrivs i Oracle Critical Patch Update. För en mer fullständig lista över buggfixar som är inkluderade i den här utgåvan går du till sidan med buggfixar i JDK 8u241.

» Versionskommentarer till 8u241

Java 8 Update 231 (8u231)

Viktiga funktioner i versionen

IANA-data 2019b
JDK 8u231 innehåller IANA-tidszonsdata version 2019b. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Ny funktion: Ny systemegenskap jdk.jceks.iterationCount
En ny systemegenskap har lagts till för att kontrollera det upprepade beräkningsvärdet för nyckellagret jceks. Standardvärdet är fortfarande 200 000, men det går att ange värden mellan 10 000 och 5 000 000. Namnet på den nya systemegenskapen är jdk.jceks.iterationCount, och värdet som anges bör vara ett heltal inom det godkända intervallet. Standardvärdet används vid tolkningsfel.
JDK-8223269 (inte allmän)
Ny funktion: Nya säkerhetshändelser för Java Flight Recorder (JFR)
Fyra nya JFR-händelser har lagts till i säkerhetsbiblioteket. Dessa händelser är avaktiverade som standard och kan aktiveras med hjälp av JFR-konfigurationsfiler eller standardalternativen för JFR.
Se JDK-8148188
Borttagna funktioner och alternativ: Borttagning av T2K Rasterizer och ICU Layout Engine från JavaFX
T2K rasterizer och ICU-layoutmotorn har tagits bort från JavaFX.
Se JDK-8187147
Övriga anteckningar: [client-libs and javaFX] GTK3 är nu standard på Linux/Unix
Senare versioner av Linux, Solaris och andra Unix-miljöer använder GTK3, men GTK2 stöds fortfarande.
Tidigare laddade JDK de äldre GTK2-biblioteken som standard. I den här versionen laddas istället GTK3-bibliotek som standard. Laddningen aktiveras vanligtvis med hjälp av Swing GTK Look And Feel.
Det tidigare beteendet kan återställas genom att använda systemegenskapen -Djdk.gtk.version=2.2
Se JDK-8222496
Övriga anteckningar: Ta bort inaktuella NIST EC-kurvor från standardinställda TLS-algoritmer
Denna ändring innebär att inaktuella NIST EC-kurvor tas bort från de standardinställda namngivna grupperna som används vid TLS-förbindelse. Följande kurvor tas bort sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1 och secp256k1.
Använd systemegenskapen jdk.tls.namedGroups för att återaktivera kurvorna. Egenskapen innehåller en kommaavgränsad lista inom citattecken med de aktiverad namngivna grupperna i inställningsordning. Exempel:
java -Djdk.tls.namedGroups="secp256r1, secp384r1, secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1" ...
JDK-8228825 (inte allmän)

Utgångsdatum för Java

Utgångsdatum för 8u231 är den 14 januari 2020. Java går ut när en ny utgåva med korrigeringar av säkerhetsrisker blir tillgänglig. För system som inte kan nå Oracle-servrarna finns det en sekundär mekanism som upphör i och med den här JRE:n (version 8u231) den 14 februari 2020. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av JRE:n om att uppdatera till den nyare versionen.

Buggfixar

» Versionsinformation till 8u231

Java 8 Update 221 (8u221)

Viktiga funktioner i versionen

IANA-data 2018i
JDK 8u221 innehåller IANA-tidszonsdata version 2018i. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Ny funktion: HotSpot Windows OS Detection identifierar Windows Server 2019 korrekt
Innan den här korrigeringen identifierades Windows Server 2019 som "Windows Server 2016", vilket gav felaktiga värden i systemegenskapen os.name och filen hs_err_pid.
Se JDK-8211106
Borttagna funktioner och alternativ: Borttagning av två DocuSign CA-rotcertifikat
Två DocuSign CA-rotcertifikat har gått ut och tagits bort från nyckellagret cacerts:
- alias "certplusclass2primaryca [jdk]"
  Unikt namn: CN=Class 2 Primary CA, O=Certplus, C=FR
- alias "certplusclass3pprimaryca [jdk]"
  Unikt namn: CN=Class 3P Primary CA, O=Certplus, C=FR
Se JDK-8223499
Borttagna funktioner och alternativ: Borttagning av två Comodo CA-rotcertifikat
Två Comodo CA-rotcertifikat har gått ut och tagits bort från nyckellagret cacerts:
- alias "utnuserfirstclientauthemailca [jdk]"
  Unikt namn: CN=UTN-USERFirst-Client Authentication and Email, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
- alias "utnuserfirsthardwareca [jdk]"
  Unikt namn: CN=UTN-USERFirst-Hardware, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
Se JDK-8222136
Borttagna funktioner och alternativ: Borttagning av T-Systems Deutsche Telekom CA-rotcertifikat 2
T-Systems Deutsche Telekom CA-rotcertifikat 2 har gått ut och tagits bort från nyckellagret cacerts:
- alias "deutschetelekomrootca2 [jdk]"
  Unikt namn: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche Telekom AG, C=DE
Se JDK-8222137
Övriga anteckningar: Provisorisk lösning för installation av Java Access Bridge
Det finns en risk att funktionerna i Java Access Bridge störs när Java installeras i ett Windows-system som har både en tidigare installerad version av Java och en instans av JAWS som körs. Efter omstart kan systemet bli utan WindowsAccessBridge-64.dll i antingen systemkatalogen (C:\Windows\System32) för 64-bitars Java-produkter eller systemkatalogen som används av WOW64 (C:\Windows\SysWoW64) för 32-bitars Java-produkter.
För att undvika att störa funktionerna i Java Access Bridge bör du använda någon av följande provisoriska lösningar:
- Stoppa JAWS innan du kör installationsprogrammet för Java.
- Avinstallera befintliga JRE:er innan du installerar den nya versionen av Java.
- Avinstallera befintliga JRE:er när den nya versionen av Java har installerats och datorn har startats om.
Målet med de provisoriska lösningarna är att undvika att avinstallera befintliga JRE:er från installationsprogrammet för Java när JAWS körs.
JDK-8223293 (inte allmän)

Utgångsdatum för Java

Utgångsdatumet för 8u221 är den 15 oktober 2019. Java går ut när en ny utgåva med korrigeringar av säkerhetsrisker blir tillgänglig. För system som inte kan nå Oracles servrar upphör en sekundär mekanism den här JRE-versionen (version 8u221) den 15 november 2019. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av JRE:n om att uppdatera till den nyare versionen.

Buggfixar

» Versionsinformation till 8u221

Java 8 Update 211 (8u211)

Viktiga funktioner i versionen

IANA-data 2018g
JDK 8u211 innehåller IANA-tidszonsdata version 2018g. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Ny funktion: Stöd för nytt tecken i samband med den nya japanska eran
Kodpunkten U+32FF har tagits fram av Unicode Consortium för att användas som tecknet för den nya japanska eran som börjar i maj 2019. Relevanta metoder i klassen Tecken returnerar samma egenskaper som de befintliga tecknen för den nuvarande japanska eran (dvs. U+337E för Meizi). Mer information om kodpunkten finns här: http://blog.unicode.org/2018/09/new-japanese-era.html.
Se JDK-8211398
Ändring: Ett nytt GlobalSign R6-rotcertifikat har lagts till
Följande rotcertifikat har lagts till i OpenJDK-cacertssäkerhetslagret:
- GlobalSign
  - globalsignrootcar6
    DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R6
JDK-8216577 (inte allmän)
Ändring: TLS-servercertifikat som förankras av en Symantec-rot upphör att vara betrodda
TLS-servercertifikat som har utfärdats av Symantec upphör att vara betrodda av JDK i linje med liknande planer meddelade av Google, Mozilla, Apple och Microsoft. Certifikat som påverkas av det här är certifikat från GeoTrust, Thawte och VeriSign som hanterades av Symantec.
TLS-servercertifikat som har utfärdats den 16 april 2019 eller tidigare fortsätter att vara betrodda tills de upphör att gälla. Certifikat som har utfärdats efter detta datum avslås. Se supportsidan DigiCert för mer information om hur du ersätter dina certifikat från Symantec med ett certifikat från DigiCert (DigiCert tog över valideringen och utfärdandet av alla Symantec Website Security SSL/TLS-certifikat 1 december 2017).
Ett undantag från den här regeln är att TLS-servercertifikat som har utfärdats via två underordnade certifikatutfärdare hanterade av Apple och namngivna här nedanför fortsätter att vara betrodda förutsatt att de har utfärdats 31 december 2019 eller tidigare.
Se JDK-8207258
Ändring: Nytt namn på japansk era
Platshållarnamnet "NewEra" för den japanska eran som började 1 maj 2019 har ersatts med namnet "Reiwa" som den japanska regeringen har förkunnat. Applikationer som kräver att platshållarnamnet går över till den nya erans singleton (JapaneseEra.valueOf("NewEra")) kommer att sluta fungera.
Se JDK-8205432
Ändring: Stöd för den nya japanska eran i java.time.chrono.JapaneseEra
Klassen JapaneseEra och dess metoder of(int) valueOf(String) samt values() har gjorts om för att kunna användas med framtida tillägg för den nya japanska eran, som t.ex. hur singleton-instanser definieras, vilka de associerade heltalsvärdena för eran är m.m.
Se JDK-8212941

Utgångsdatum för Java

Utgångsdatum för 8u211 är 16 juli 2019. Java går ut när en ny utgåva med korrigeringar av säkerhetsrisker blir tillgänglig. För system som inte kan nå Oracle-servrarna finns det en sekundär mekanism som upphör den här JRE:n (version 8u211) den 16 augusti 2019. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av JRE:n om att uppdatera till den nyare versionen.

Buggfixar

Den här utgåvan innehåller programfixar för säkerhetsrisker som beskrivs i Oracle Java SE Critical Patch Update Advisory. För en lista över buggfixar som är inkluderade i den här utgåvan går du till sidan med buggfixar i JDK 8u211.

» Versionskommentarer till 8u211

Java 8 Update 201 (8u201)

Viktiga funktioner i versionen

IANA-data 2018e
JDK 8u201 innehåller IANA-tidszonsdata version 2018e. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Ändring: TLS- (anonyma) och NULL-krypteringssviterna har avaktiverats.
TLS- (anonyma) och NULL-krypteringssviterna har lagts till i säkerhetsegenskapen jdk.tls.disabledAlgorithms och är nu avaktiverade som standard.
Se JDK-8211883
Ändring: jarsigner gör en utskrift när en tidsstämpel upphör
Nu visar verktyget jarsigner mer information om livslängden på ett tidsstämplat javaarkiv. Nya varnings- och felmeddelanden visas när en tidsstämpel har upphört eller kommer att upphöra inom ett år.
Se JDK-8191438

Utgångsdatum för Java

Utgångsdatum för 8u201 är den 16 april 2019. Java går ut när en ny utgåva med korrigeringar av säkerhetsrisker blir tillgänglig. För system som inte kan nå Oracles servrar avaktiverar en sekundär mekanism den här JRE-versionen (version 8u201) den 16 maj 2019. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av JRE:n om att uppdatera till den nyare versionen.

Buggfixar

» Versionskommentarer till 8u201

Java 8 Update 191 (8u191)

Viktiga funktioner i versionen

IANA-data 2018e
JDK 8u191 innehåller IANA-tidszonsdata version 2018e. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Ändring: Den centrala filsystemplatsen har ändrats för usagetracker.properties-filen
Filsystemplatsen i Windows för usagetracker.properties-filen har flyttats från %ProgramData%\Oracle\Java\ till %ProgramFiles%\Java\conf
Filsökvägen har inte ändrats för Linux, Solaris eller macOS. JDK-8204901 (inte allmän)
Ändring: Alla DES TLS-krypteringssviter har avaktiverats
DES-baserade TLS-krypteringssviter anses vara inaktuella och bör inte längre användas. DES-baserade krypteringssviter har avaktiverats som standard i SunJSSE-implementeringen genom tillägg av identifieraren "DES" i säkerhetsegenskapen jdk.tls.disabledAlgorithms. De här krypteringssviterna kan återaktiveras genom borttagning av "DES" från säkerhetsegenskapen jdk.tls.disabledAlgorithms i java.security-filen eller genom dynamiskt anropande av metoden Security.setProperty(). Efter DES-återaktiveringen måste du i båda fallen lägga till DES-baserade krypteringssviter i listan över aktiverade krypteringssviter genom att använda metoderna SSLSocket.setEnabledCipherSuites() eller SSLEngine.setEnabledCipherSuites().
Observera att före den här ändringen avaktiverades DES40_CBC-sviterna (men inte alla DES-sviter) via säkerhetsegenskapen jdk.tls.disabledAlgorithms.
Se JDK-8208350
Ändring: Flera Symantec-rotcertifikatutfärdare har tagits bort
Följande Symantec-rotcertifikat används inte längre och har tagits bort:
- Symantec
  - equifaxsecureca
    DN: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
  - equifaxsecureglobalebusinessca1
    DN: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US
  - equifaxsecureebusinessca1
    DN: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US
  - verisignclass1g3ca
    DN: CN=VeriSign Class 1 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
  - verisignclass2g3ca
    DN: CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
  - verisignclass1g2ca
    DN: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
  - verisignclass1ca
    DN: OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
Se JDK-8191031
Ändring: Baltimore Cybertrust Code Signing-CA har tagits bort
Följande Baltimore CyberTrust Code Signing-rotcertifikat används inte längre och har tagits bort:
- baltimorecodesigningca
  DN: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE
Se JDK-8189949
Buggfix: LDAPS-kommunikationsfel
Applikationskod som använder LDAPS med en tidsgräns för socketanslutning som är <= 0 (standardvärdet) kan, vid körning i CPU-utgåvan från juli 2018 ( 8u181, 7u191 och 6u201 ), påträffa ett undantag under upprättande av anslutningen.
De översta ramarna i undantagsstackspårningarna för applikationer som påträffar sådana fel kan se ut på följande sätt:
javax.naming.ServiceUnavailableException: ; socket closed
at com.sun.jndi.ldap.Connection.readReply(Unknown Source)
at com.sun.jndi.ldap.LdapClient.ldapBind(Unknown Source) ...
Felet har åtgärdats och korrigeringen finns tillgänglig i följande utgåvor:
- 8u181
- 7u191
Se JDK-8211107

Utgångsdatum för Java

Utgångsdatum för 8u191 är den 15 januari 2019. Java går ut när en ny utgåva med korrigeringar av säkerhetsrisker blir tillgänglig. För system som inte kan nå Oracle-servrarna finns det en sekundär mekanism som går ut i den här JRE:n (version 8u191) den 15 februari 2019. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av JRE:n om att uppdatera till den nyare versionen.

Buggfixar

Den här utgåvan innehåller programfixar för säkerhetsrisker som beskrivs i Oracle Java SE Critical Patch Update Advisory. För en mer fullständig lista över buggfixar som är inkluderade i den här utgåvan går du till sidan med buggfixar i JDK 8u191.

» Versionsinformation till 8u191

Java 8 Update 181 (8u181)

Viktiga funktioner i versionen

IANA-data 2018e
JDK 8u181 innehåller IANA-tidszonsdata version 2018e. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Borttagen funktion: Java DB har tagits bort
Java DB, som även kallas för Apache Derby, har tagits bort i den här utgåvan.
Oracle rekommenderar att du hämtar den senaste versionen av Apache Derby direkt från Apache-projektet på:
https://db.apache.org/derby
JDK-8197871 (inte allmän)
Ändring: Förbättrat LDAP-stöd
Slutpunktsidentifiering har aktiverats för LDAPS-anslutningar.
För att förbättra tillförlitligheten för LDAPS-anslutningar (säker LDAP över TLS) är algoritmerna för slutpunktsidentifiering aktiverade som standard.
Det kan finnas situationer när vissa applikationer som tidigare kunde ansluta till en LDAPS-server inte längre kan göra det. För den typen av applikationer kan du avaktivera slutpunktsidentifieringen med en ny systemegenskap: com.sun.jndi.ldap.object.disableEndpointIdentification.
Definiera den här systemegenskapen (eller ange den till true) för att avaktivera algoritmerna för slutpunktsidentifiering.
JDK-8200666 (inte allmän)
Förändring: Bättre stacksstegning
Nya åtkomstkontroller har lagts till under fasen för att skapa objekt under avserialiseringen. Det bör inte påverka vanlig avserialiseringsanvändning. Reflexiva ramverk som använder JDK-interna API:er kan påverkas. Du kan avaktivera de nya kontrollerna genom att ange systemegenskapen jdk.disableSerialConstructorChecks till värdet "true". Du måste göra det genom att lägga till argumentet -Djdk.disableSerialConstructorChecks=true på kommandoraden för Java.
JDK-8197925 (inte allmän)
Buggfix: JVM-krasch under G1 GC
En klass som har betraktats som tillgänglig för samtidig märkning av G1 kan slås upp i ClassLoaderData/SystemDictionary och fälten _java_mirror eller _class_loader kan lagras i en rot eller i ett annat tillgängligt objekt som gör den aktiv igen. När en klass återupptas på det här sättet måste SATB-delen av G1 meddelas, i annat fall avaktiverar den samtidiga märkningsanmärkningsfasen den klassen på fel sätt.
Se JDK-8187577
Buggfix: Bättre stabilitet med äldre NUMA-bibliotek (-XX+UseNuma)
En fix som ingår i JDK 8 Update 152 introducerade en regression som kan orsaka att HotSpot JVM kraschar vid start när flaggan UseNUMA används i Linux-system med versioner av libnuma som är äldre än 2.0.9. Det här problemet är löst.
Se JDK-8198794

Utgångsdatum för Java

Utgångsdatum för 8u181 är den 16 oktober 2018. Java går ut när en ny utgåva med korrigeringar av säkerhetsrisker blir tillgänglig. För system som inte kan nå Oracles servrar upphör en sekundär mekanism den här JRE-versionen (version 8u181) den 16 november 2018. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av JRE:n om att uppdatera till den nyare versionen.

Buggfixar

» Versionskommentarer till 8u181

Java 8 Update 171 (8u171)

Viktiga funktioner i versionen

IANA-data 2018c
JDK 8u171 innehåller IANA-tidszonsdata version 2018c. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Ny funktion: Förbättrade KeyStore-mekanismer
En ny säkerhetsegenskap med namnet jceks.key.serialFilter har lagts till. Om du konfigurerar det här filtret använder KeyStore för JCEKS det under avserialiseringen av krypterade nyckelobjekt som är lagrade i en SecretKeyEntry. Om du inte konfigurerar det eller om filterresultatet är UNDECIDED (till exempel när inga mönster matchar) används det filter som är konfigurerat av jdk.serialFilter.
Om du även anger systemegenskapen jceks.key.serialFilter åsidosätter den det säkerhetsegenskapsvärde du definierar här.
Filtermönstret använder samma format som jdk.serialFilter. Standardmönstret tillåter java.lang.Enum, java.security.KeyRep, java.security.KeyRep$Type och javax.crypto.spec.SecretKeySpec men avslår alla andra.
Om du lagrar en SecretKey som inte serialiseras till de typer som är angivna ovan måste du ändra filtret för att göra nyckeln extraheringsbar.
JDK-8189997 (inte allmän)
Ny funktion: Systemegenskap för att aktivera spårning av senaste JRE-användning
Den nya systemegenskapen jdk.disableLastUsageTracking har lagts till för att avaktivera spårning av senaste JRE-användning för en VM som körs. Du kan ange egenskapen på kommandoraden med -Djdk.disableLastUsageTracking=true eller -Djdk.disableLastUsageTracking. När du anger den här systemegenskapen avaktiveras spårning av senaste JRE-användning oavsett värdet på egenskapen com.oracle.usagetracker.track.last.usage i usagetracker.properties.
JDK-8192039 (inte allmän)
Obs! Syntax för CipherOutputStream
Specifikationen för javax.crypto.CipherOutputStream har förtydligats för att ange att den här klassen fångar BadPaddingException och andra undantag som kastades av ej utförda integritetskontroller under dekrypteringen. De här undantagen kastades inte igen vilket medför att klienten inte informeras om att integritetskontrollerna inte har utförts. På grund av det här beteendet är den här klassen eventuellt inte lämplig att använda med dekryptering i autentiserat åtgärdsläge (som GCM) om applikationen kräver ett explicit meddelande när autentiseringen inte utförs. De applikationerna kan använda chiffer-API:t som ett alternativ till att använda den här klassen.
JDK-8182362 (inte allmän)
Ändring: Ett nytt TeliaSonera-rotcertifikat,
"TeliaSonera Root CA v1", har lagts till i nyckellagret cacerts.
JDK-8190851 (inte allmän)
Ändring: XML-signaturer som är signerade med EC-nycklar som är kortare än 224 bitar är avaktiverade
För att förbättra styrkan för SSL-/TLS-anslutningar har 3DES-chiffersystemet avaktiverats i SSL-/TLS-anslutningar i JDK:t med säkerhetsegenskapen jdk.tls.disabledAlgorithms.
JDK-8175075 (inte allmän)
Buggfix: HTTP-tunnlade RMI-anslutningar på serversidan är avaktiverade
HTTP-tunnlade RMI-anslutningar på serversidan är avaktiverade som standard i den här utgåvan. Du kan återställa det här beteendet genom att ange exekveringsegenskapen sun.rmi.server.disableIncomingHttp till false. Förväxla inte det här med egenskapen sun.rmi.server.disableHttp som avaktiverar HTTP-tunnling på klientsidan och som är false som standard.
JDK-8193833 (inte allmän)

Utgångsdatum för Java

Utgångsdatum för 8u171 är den 17 juli 2018. Java går ut när en ny utgåva med korrigeringar av säkerhetsrisker blir tillgänglig. För system som inte kan nå Oracle-servrarna finns det en sekundär mekanism som upphör den här JRE:n (version 8u171) den 17 augusti 2018. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av JRE:n om att uppdatera till den nyare versionen.

Buggfixar

» Versionskommentarer till 8u171

Java 8 Update 161 (8u161)

Viktiga funktioner i versionen

IANA-data 2017c
JDK 8u161 innehåller IANA-tidszonsdata version 2017c. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Ny funktion: Stöd för DHE-storlekar upp till 8192 bitar och DSA-storlekar upp till 3072 bitar
JDK-säkerhetsleverantörerna har förbättrats så att de stöder generering av DiffieHellman- och DSA-parametrar med upp till 3072 bitar, förberäknade DiffieHellman-parametrar upp till 8192 bitar och förberäknade DSA-parametrar upp till 3072 bitar.
Se JDK-8072452
Ny funktion: Förhandlade FFDHE-parametrar (Finite Field Diffie-Hellman Ephemeral) för TLS
Implementationen av JDK:t SunJSSE stöder nu FFDHE-mekanismer för TLS enligt definitionen i RFC 7919. Om en server inte kan bearbeta TLS-tillägget supported_groups eller de namngivna grupperna i tillägget kan applikationer anpassade de gruppnamn som stöds med jdk.tls.namedGroups eller avaktivera FFDHE-mekanismerna genom att ange systemegenskapen jsse.enableFFDHEExtension till false.
Se JDK-8140436
Ny funktion: Ytterligare kontroll av IDL-stubbtyper har lagts till i metoden org.omg.CORBA.ORBstring_to_object
Applikationer som anropar org.omg.CORBA.ORB.string_to_object explicit eller implicit och vill kontrollera integriteten för den IDL-stubbtyp som ingår i ORB::string_to_object-anropsflödet ska ange ytterligare kontroll av IDL-stubbtyper. Den här funktionen är inte aktiverad som standard.
För att använda den ytterligare typkontrollen konfigurerar du listan över giltiga IDL-gränssnittsklassnamn med IDL-stubbklasser genom att göra något av följande:
- Ange säkerhetsegenskapen com.sun.CORBA.ORBIorTypeCheckRegistryFilter som finns i filen conf/security/java.security i Java SE 9 och i jre/lib/security/java.security i Java SE 8 och tidigare.
- Ange systemegenskapen com.sun.CORBA.ORBIorTypeCheckRegistryFilter med listan över klasser. Om du anger systemegenskapen åsidosätter värdet för den motsvarande egenskap som du har definierat i konfigurationen java.security.
Om du inte anger egenskapen com.sun.CORBA.ORBIorTypeCheckRegistryFilter utförs endast typkontrollen mot en uppsättning med klassnamn med de IDL-gränssnittstyper som motsvarar de inbyggda IDL-stubbklasserna.
JDK-8160104 (inte allmän)
Ändring: Validering av öppna RSA-nycklar
I 8u161 avslår RSA-implementationen i leverantören SunRsaSign öppna RSA-nycklar som har en exponent som inte finns i det giltiga intervallet enligt definitionen i PKCS#1 version 2.2. Den här ändringen påverkar JSSE-anslutningar samt applikationer som bygger på JCE.
JDK-8174756 (inte allmän)
Ändring: Begränsning av Diffie-Hellman-nycklar som är kortare än 1024 bitar
Diffie-Hellman-nycklar som är kortare än 1024 bitar anses som för svaga att använda och ska begränsas som standard i SSL-/TLS-/DTLS-anslutningar. På grund av det har Diffie-Hellman-nycklar som är kortare än 1024 bitar avaktiverats som standard genom att lägga till "DH keySize< 1024" i säkerhetsegenskapen "jdk.tls.disabledAlgorithms" i filen java.security. Även om det inte rekommenderas, men om du är administratör kan du uppdatera säkerhetsegenskapen "jdk.tls.disabledAlgorithms" och tillåta kortare nyckelstorlekar (till exempel genom att ange "DH keySize< 768").
JDK-8148108 (inte allmän)
Ändring: Standardstorleken för leverantörsnycklar har uppdaterats
Den här ändringen uppdaterar JDK-leverantörer så att de använder 2048 bitar som standardnyckelstorlek för DSA i stället för 1024 bitar när applikationer inte har initierat java.security.KeyPairGenerator- och java.security.AlgorithmParameterGenerator-objekt med en nyckelstorlek.
Om det uppstår kompatibilitetsproblem kan befintliga applikationer ange systemegenskapen jdk.security.defaultKeySize som introducerades i JDK-8181048 med en algoritm med önskad standardnyckelstorlek.
JDK-8178466 (inte allmän)

Utgångsdatum för Java

Utgångsdatum för 8u161 är den 17 april 2018. Java går ut när en ny utgåva med korrigeringar av säkerhetsrisker blir tillgänglig. För system som inte kan nå Oracles servrar upphör en sekundär mekanism den här JRE:n (8u161) den 17 maj 2018. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av JRE:n om att uppdatera till den nyare versionen.

Buggfixar

» Versionskommentarer till 8u161

Java 8 Update 151 (8u151)

Viktiga funktioner i versionen

IANA-data 2017b
JDK 8u151 innehåller IANA-tidszonsdata version 2017b. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Certifikatändringar: Tog bort det återkallade Swisscom-rotcertifikatet "swisscomrootevca2"
Ett Swisscom-rotcertifikat har återkallats av Swisscom och har tagits bort: Swisscom Root EV CA 2 alias: "swisscomrootevca2 [jdk]" DN: CN=Swisscom Root EV CA 2, OU=Digital Certificate Services, O=Swisscom, C=ch
JDK-8186330 (inte allmän)
Nya funktioner Ny säkerhetsegenskap för att kontrollera kryptografipolicy
Den här utgåvan innehåller en ny funktion där JCE-jurisdiktionspolicyfiler som används av JDK:t kan kontrolleras via en ny säkerhetsegenskap. I gamla utgåvor måste JCE-jurisdiktionsfiler laddas ned och installeras separat för att tillåta att obegränsad kryptografi användes av JDK:t. Nedladdnings- och installationsstegen är inte längre nödvändiga. För att aktivera obegränsad kryptografi använder du den nya säkerhetsegenskapen crypto.policy. Om den nya säkerhetsegenskapen (crypto.policy) anges i filen java.security eller har angetts dynamiskt genom att använda anropet Security.setProperty() före initiering av JCE-ramverket används inställningen. Som standard är egenskapen odefinierad. Om egenskapen är odefinierad och de äldre JCE-jurisdiktionsfilerna inte finns i den äldre katalogen lib/security är standardkryptografinivån fortfarande "limited". För att konfigurera JDK:t att använda obegränsad kryptografi anger du crypto.policy till "unlimited". Mer information finns i filen java.security som levereras med den här utgåvan.
Obs! I Solaris bör du ta bort de gamla SVR4-paketen innan du installerar de nya JDK-uppdateringarna. Om du utför en SVR4-baserad uppgradering (utan att avinstallera de gamla paketen) på en JDK-utgåva före 6u131, 7u121 respektive 8u111 bör du ange den nya säkerhetsegenskapen crypto.policy i filen java.security.

Eftersom de gamla JCE-jurisdiktionsfilerna inte tas bort från <hemkatalogen för Java>/lib/security kanske de inte uppfyller de senaste JAR-signeringsstandarderna, som förnyades i 6u131, 7u121 respektive 8u111, och senare uppdateringar. Ett undantag som liknar följande kan visas om de gamla filerna används:

Orsakades av: java.lang.SecurityException: Jurisdiktionspolicyfilerna har inte signerats av tillförlitliga signerare! på javax.crypto.JceSecurity.loadPolicies(JceSecurity.java:593) på javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:524)
Se JDK-8157561
Ändringar Befintliga leverantörer har omfaktoriserats för att hänvisa till samma konstanter för standardvärden för nyckellängd
Två viktiga ändringar har gjorts för det här problemet:
1. En ny systemegenskap har lagts till som användare kan använda för att konfigurera den standardnyckelstorlek som används av JDK-leverantörsimplementationerna av KeyPairGenerator och AlgorithmParameterGenerator. Egenskapen med namnet "jdk.security.defaultKeySize" och värdet på den här egenskapen är en lista över kommaavgränsade poster. Varje post består av ett skiftlägesokänsligt algoritmnamn och motsvarande standardnyckelstorlek (decimalt) avgränsade med ":". Dessutom ignoreras blanktecken.
Som standard har den här egenskapen inget värde och JDK-leverantörer använder sina egna standardvärden. Poster som innehåller ett algoritmnamn som inte känns igen ignoreras. Om den angivna standardnyckelstorleken inte är ett tolkningsbart decimalt heltal ignoreras posten också.
1. DSA KeyPairGenerator-implementationen för SUN-leverantören implementerar inte längre java.security.interfaces.DSAKeyPairGenerator. Applikationer som anropar DSA KeyPairGenerator-objektet för SUN-leverantören till java.security.interfaces.DSAKeyPairGenerator kan ange systemegenskapen "jdk.security.legacyDSAKeyPairGenerator". Om värdet på den här egenskapen är "true" returnerar SUN-leverantören ett DSA KeyPairGenerator-objekt som implementerar gränssnittet java.security.interfaces.DSAKeyPairGenerator. Den här äldre implementation använder samma standardvärde som har angetts av javadoc i gränssnittet.
Som standard har den här egenskapen inte något värde och SUN-leverantören returnerar ett DSA KeyPairGenerator-objekt som inte implementerar gränssnittet ovan och därför kan fastställa sitt eget leverantörsspecifika standardvärde enligt klassen java.security.KeyPairGenerator eller genom att systemegenskapen "jdk.security.defaultKeySize" inte har angetts.
JDK-8181048 (inte allmän)

Utgångsdatum för Java

Utgångsdatum för 8u151 är den 16 januari 2018. Java går ut när en ny utgåva med korrigeringar av säkerhetsrisker blir tillgänglig. För system som inte kan nå Oracle-servrarna finns det en sekundär mekanism som upphör den här JRE:n (version 8u151) den 16 februari 2018. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av JRE:n om att uppdatera till den nyare versionen.

Buggfixar

» Versionskommentarer till 8u151

Java 8 Update 144 (8u144)

Viktiga funktioner i versionen

IANA-data 2017b
JDK 8u144 innehåller IANA-tidszonsdata version 2017b. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Buggfix: java.util.zip.ZipFile.getEntry() returnerar nu alltid ZipEntry-instansen med ett "/" i slutet av postnamnen för katalogposter
java.util.zip.ZipEntry API-dokument anger 'En katalogpost är definierad som en post med ett namn som slutar med ett /'. I tidigare JDK-utgåvor kan java.util.zip.ZipFile.getEntry(String entryName) returnera en ZipEntry-instans med ett postnamn som inte slutar med / för en befintlig katalogpost, när det överförda argumentet entryName inte slutar med ett / och det finns en matchande komprimerad katalogpost med namnet entryName + / i den komprimerade filen. I den här utgåvan slutar alltid namnet på den ZipEntry-instans som returnerades från java.util.zip.ZipFile.getEntry() med / för alla komprimerade katalogposter.
Om du vill återställa det tidigare beteendet anger du systemegenskapen jdk.util.zip.ensureTrailingSlash till "false".

Ändringen gjordes för att korrigera en regression som introducerades i JDK 8u141 när signerade JAR-filer verifierades vilket gjorde att vissa Web Start-applikationer inte kunde laddas.
Se JDK-8184993

Utgångsdatum för Java

Utgångsdatum för 8u144 är den 17 oktober 2017. Java går ut när en ny utgåva med korrigeringar av säkerhetsrisker blir tillgänglig. För system som inte kan nå Oracles servrar upphör en sekundär mekanism den här JRE-versionen (version 8u144) den 17 november 2017. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av JRE:n om att uppdatera till den nyare versionen.

Buggfixar

» Versionskommentarer till 8u144

Java 8 Update 141 (8u141)

Viktiga funktioner i versionen

IANA-data 2017b
JDK 8u141 innehåller IANA-tidszonsdata version 2017b. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Certifikatändringar: Ett nytt Let's Encrypt-certifikat har lagts till bland rotcertifikatinstanserna
Ett nytt rotcertifikat har lagts till:
ISRG Root X1 alias: letsencryptisrgx1 DN: CN=ISRG Root X1, O=Internet Security Research Group, C=US
JDK-8177539 (inte allmän)
Förbättringar av JMX-diagnostiken
API:t com.sun.management.HotSpotDiagnostic::dumpHeap har ändrats så att det kastar IllegalArgumentException om det angivna filnamnet inte slutar med suffixet ".hprof". Befintliga applikationer som inte anger ett filnamn som sluter med tillägget ".hprof" utförs inte med IllegalArgumentException. I så fall kan applikationerna hantera undantaget eller återställa det gamla beteendet genom att ange systemegenskapen "jdk.management.heapdump.allowAnyFileSuffix" till "true".
JDK-8176055 (inte allmän)
Bättre säkerhetskontroller vid bearbetning av WSDL-filer av verktyget wsimport
Verktyget wsimport har ändrats så att det inte tillåter DTD:er i beskrivningar av webbtjänster. Följande ändringar har utförts:
- DOCTYPE-deklarationen är inte tillåten i dokument
- Externa allmänna entiteter inkluderas inte som standard
- Externa parameterentiteter inkluderas inte som standard
- Externa DTD:er ignoreras
Så här återställer du det tidigare beteendet:
- Ange systemegenskapen com.sun.xml.internal.ws.disableXmlSecurity till "true"
- Använd kommandoradsalternativet -disableXmlSecurity för verktyget wsimport
  Obs! Stöd för det här alternativet i wsimport i JDK 7 och JDK 6 tillhandahålls i en programfixutgåva efter CPU-utgåvan i juli
JDK-8182054 (inte allmän)
Anpassat HostnameVerifier aktiverar SNI-tillägg
Tidigare utgåvor av JDK 8-uppdateringar skickade inte alltid SNI-tillägget (Server Name Indication) under ClientHello-fasen för TLS om en anpassad värdnamnsverifierare användes. Den här verifieraren anges via metoden setHostnameVerifier(HostnameVerifier v) i HttpsURLConnection. Den här korrigeringen ser till att servernamnet skickas i ClientHello-meddelandet.
Se JDK-8144566
Förbättrad kontroll av algoritmbegränsningar
Eftersom det finns ett behov av att begränsa användningen av svaga algoritmer i situationer där de är som mest sårbara har ytterligare funktioner lagts till vid konfiguration av säkerhetsegenskapen jdk.certpath.disabledAlgorithms och jdk.jar.disabledAlgorithms i filen java.security.
jdk.certpath.disabledAlgorithms: egenskapen certpath har ändrats mest. Tidigare var den begränsad till två begränsningstyper: en fullständig avaktivering av en algoritm per namn eller en fullständig avaktivering av en algoritm per nyckelstorlek vid kontroll av certifikat, certifikatkedjor och certifikatsignaturer. Det här innebär att konfigurationer som är absoluta och inte är flexibla skapas. Tre nya begränsningar har lagts till för att göra det mer flexibelt att tillåta eller avslå certifikat.

"jdkCA" kontrollerar avslutandet av certifikatkedjan med hänsyn till filen cacerts. För "SHA1 jdkCA". Användningen av SHA1 kontrolleras via certifikatkedjan men kedjan måste avslutas vid ett markerat säkerhetsankare i nyckellagret cacerts för att avslås. Det här är användbart för organisationer som har en egen privat certifikatinstans som utfärdar säkerhet med SHA1 med ett eget säkerhetsankare men som vill blockera certifikatkedjor med en allmän certifikatinstans som ankare från att använda SHA1.

"denyAfter" kontrollerar om det angivna datumet är tidigare än det aktuella datumet eller datumet i PKIXParameter. För "SHA1 denyAfter 2018-01-01": före 2018 kan ett certifikat med SHA1 användas men efter det datumet avslås certifikatet. Det här kan användas för en policy inom en organisation som fasar ut en algoritm med ett slutdatum. För signerade JAR-filer jämförs datumet med TSA-tidsstämpeln. Datum anges i GMT.

"usage" kontrollerar användningen för den angivna algoritmen. Det här kan användas när det inte är praktiskt möjligt att avaktivera en algoritm för alla användningar. Det finns tre användningar som kan anges:
- "TLSServer" begränsar algoritmen i TLS-servercertifikatkedjor när serverautentiseringen utförs som en klient.
- "TLSClient" begränsar algoritmen i TLS-servercertifikatkedjor när klientautentiseringen utförs som en server.
- "SignedJAR" begränsar algoritmer i certifikat i signerade JAR-filer. Användningstypen följer nyckelordet och fler än en användningstyp kan anges med ett blanktecken.
  Exempel: "SHA1 usage TLSServer TLSClient" tillåter inte SHA1-certifikat för TLSServer- och TLSClient-åtgärder, men SignedJars tillåts
Alla de här begränsningarna kan kombineras för att begränsa en algoritm när de avgränsas med "&". Exempel: Om du vill avaktivera SHA1-certifikatkedjor som avslutas vid markerade säkerhetsankare för TLSServer-åtgärder är begränsningen "SHA1 jdkCA & usage TLSServer".

jdk.jar.disabledAlgorithms: en ytterligare begränsning har lagts till den här .jar-egenskapen för att begränsa JAR-manifestalgoritmer.

"denyAfter" kontrollerar algoritmbegränsningar i manifesthashningsalgoritmer i en signerad JAR-fil. Det datum som anges i begränsningen jämförs med TSA-tidsstämpeln för den signerade JAR-filen. Om det inte finns någon tidsstämpel eller om tidsstämpeln är samma som eller senare än det angivna datumet behandlas den signerade JAR-filen som osignerad. Om tidsstämpel är tidigare än det angivna datumet körs .jar-filen som en signerad JAR-fil. Syntaxen för att begränsa SHA1 i JAR-filer som har signerats efter den 1 januari 2018 är: "SHA1 denyAfter 2018-01-01". Syntaxen är samma som för egenskapen certpath men certifikatkontroll utförs inte av den här egenskapen.
Se JDK-8176536

Utgångsdatum för Java

Utgångsdatum för 8u141 är den 17 oktober 2017. Java går ut när en ny utgåva med korrigeringar av säkerhetsrisker blir tillgänglig. För system som inte kan nå Oracles servrar upphör en sekundär mekanism den här JRE-versionen (version 8u141) den 17 november 2017. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av JRE:n om att uppdatera till den nyare versionen.

Buggfixar

» Versionskommentarer till 8u141

Java 8 Update 131 (8u131)

Viktiga funktioner i versionen

IANA-data 2016j
JDK 8u131 innehåller IANA-tidszonsdata version 2016j. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Buggfix: Ny fönsterordningsmodell
På plattformen OS X använde AWT-ramverket inbyggda tjänster för att implementera överordnad/underordnad-relationer för fönster. Det medförde vissa oönskade visuella effekter, särskilt i miljöer med flera skärmar. För att undvika nackdelarna med det tillvägagångssättet har en ny fönsterordningsmodell, som har implementerats fullständigt i JDK-lagret, introducerats. Huvudprinciperna för den beskrivs nedan:
- Ett fönster ska placeras över sitt närmast överordnade fönster.
- Om ett fönster har flera underordnade fönster ska alla underordnade fönster placeras i samma skikt och fönstret från den aktiva fönsterkedjan ska ordnas över sina jämställda fönster.
- Ordningen ska inte ändras på ett fönster som är minimerat eller när övergången till minimerat tillstånd pågår.
De här reglerna ska användas på alla ramar och dialogrutor från den fönsterhierarki som innehåller det fönster som har fokus. Se JDK-8169589
Buggfix: Korrigering av IllegalArgumentException från TLS-handskakning
Ett problem i fixen JDK-8173783 kan medföra problem för vissa TLS-servrar. Problemet kommer från ett IllegalArgumentException som kastades av koden för TLS-handskakning:

java.lang.IllegalArgumentException: Systemegenskapen jdk.tls.namedGroups(null) innehåller inga elliptiska kurvor som stöds

Problemet kan uppstå när servern inte har stöd för kryptografi med elliptiska kurvor för att hantera ett tilläggsfält med namnet på en elliptisk kurva (om tillgängligt). Du bör uppgradera till den här utgåvan. Som standard levereras JDK 7-uppdateringar och senare JDK-familjer med säkerhetsleverantören SunEC som innehåller stöd för kryptografi med elliptiska kurvor. De utgåvorna bör inte påverkas om inte säkerhetsleverantörerna ändras. Se JDK-8173783
MD5 har lagts till i säkerhetsegenskapen jdk.jar.disabledAlgorithms
I den här JDK-utgåvan finns det en ny begränsning för hur MD5-signerade JAR-filer verifieras. Om den signerade JAR-filen använder MD5 ignorerar signaturverifieringsåtgärder signaturen och behandlar JAR-filen som om den var osignerad. Det här kan inträffa i följande typer av applikationer som använder signerade JAR-filer:
- Appletar och Web Start-applikationer
- Fristående applikationer och serverapplikationer där SecurityManager är aktiverat och som är konfigurerade med en policyfil som tilldelar behörigheter baserat på kodsigneraren/-signerarna för JAR-filen.
Listan över avaktiverade algoritmer kontrolleras via säkerhetsegenskapen jdk.jar.disabledAlgorithms i filen java.security. Den här listan innehåller en lista över avaktiverade algoritmer och nyckelstorlekar för kryptografiskt signerade JAR-filer.

Om du vill kontrollera om en svag algoritm eller nyckel har använts för att signera en JAR-fil kan du använda binärfilen jarsigner som levereras med det här JDK:t. Om du kör "jarsigner -verify" på en JAR-fil som har signerats med en svag algoritm eller nyckel skrivs mer information om den avaktiverade algoritmen respektive nyckeln ut.

Exempel: Om du vill kontrollera en JAR-fil med namnet test.jar använder du följande kommando:

jarsigner -verify test.jar

Om filen i det här exemplet signerades med en svag signaturalgoritm som MD5withRSA skulle följande utdata visas:

JAR-filen behandlas som osignerad eftersom den signerades med en svag algoritm som nu har avaktiverats. Kör jarsigner igen med alternativet -verbose om du vill ha mer information.

Du kan visa mer information genom använda alternativet verbose:

jarsigner -verify -verbose test.jar

Följande utdata skulle visas:
```
 - 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 
```
Om du vill åtgärda problemet måste du signera om JAR-filen med en kraftfullare algoritm eller med en större nyckelstorlek. Alternativt så kan du återställa begränsningarna genom att ta bort de svaga algoritmerna och nyckelstorlekarna från säkerhetsegenskapen jdk.jar.disabledAlgorithms. Det alternativet rekommenderas dock inte. Innan du signerar om de påverkade JAR-filerna ska du ta bort de befintliga signaturerna från dem. Du kan använda verktyget zip till att göra det, enligt följande:

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

Du bör kontrollera sidan Oracle JRE and JDK Cryptographic Roadmap på http://java.com/cryptoroadmap med regelbundet för mer information om planerade begränsningar för signerade JAR-filer och andra säkerhetskomponenter. JDK-8171121 (inte allmän)
Ny systemegenskap för att kontrollera cachning för SPNEGO-anslutningar via HTTP.
En ny JDK-implementationsspecifik systemegenskap för att kontrollera cachning för SPNEGO-anslutningar (Negotiate/Kerberos) via HTTP har lagts till. Cachning för SPNEGO-anslutningar via HTTP är fortfarande aktiverat som standard vilket innebär att om du inte anger egenskapen explicit kommer inte beteendet att ändras. När du ansluter till en HTTP-server där SPNEGO används för att förhandla autentisering och när anslutningen till och autentiseringen med servern har slutförts cachas autentiseringsinformation och återanvänds för ytterligare anslutningar till samma server. Dessutom, när du ansluter till en HTTP-server med SPNEGO innebär det vanligtvis att du måste se till att den underliggande anslutningen förblir aktiv och återanvända den för ytterligare begäran till samma server. I vissa applikationer kan det vara önskvärt att avaktivera all cachning för protokollet SPNEGO (Negotiate/Kerberos) via HTTP för att tvinga begärande av en ny autentisering vid varje ny begäran till servern.

Med den här ändringen finns det nu en ny systemegenskap för att kontrollera cachningspolicyn för SPNEGO-anslutningar via HTTP. Om du definierar jdk.spnego.cache och den utvärdas till "false" avaktiveras all cachning för SPNEGO-anslutningar via HTTP. Om du anger den här systemegenskapen till "false" kan det innebära vissa oönskade sidoeffekter:
- Prestanda för SPNEGO-anslutningar via HTTP kan försämras betydligt eftersom anslutningen måste omautentiseras för varje begäran, vilket kräver flera kommunikationsutbyten med servern.
- Inloggningsuppgifterna måste hämtas igen för varje ny begäran, vilket, beroende på om transparent autentisering är tillgängligt eller inte, och, beroende på den globala autentiserarimplementation, kan medföra att en popup visas som ber användaren om inloggningsuppgifter för varje ny begäran.
JDK-8170814 (inte allmän)
Ny systemegenskap för att kontrollera cachning för NTLM-anslutningar via HTTP.
En ny JDK-implementationsspecifik systemegenskap för att kontrollera cachning för NTLM-anslutningar via HTTP har lagts till. Cachning för NTLM-anslutningar via HTTP är fortfarande aktiverat som standard vilket innebär att om du inte anger egenskapen explicit kommer inte beteendet att ändras. På vissa plattformar kan implementationen för NTLM via HTTP i JDK:t användas för transparent autentisering, där systemanvändarinloggningsuppgifterna används på systemnivå. När transparent autentisering inte är tillgängligt eller inte kan utföras stöder JDK:t endast hämtning av inloggningsuppgifter från en global autentiserare. Om autentiseringen med servern slutförs cachas autentiseringsinformation och återanvänds för ytterligare anslutningar till samma server. Dessutom, när du ansluter till en HTTP-server med NTLM innebär det vanligtvis att du måste se till att den underliggande anslutningen förblir aktiv och återanvända den för ytterligare begäran till samma server. I vissa applikationer kan det vara önskvärt att avaktivera all cachning för protokollet NTLM via HTTP för att tvinga begärande av en ny autentisering vid varje ny begäran till servern.

Med den här ändringen finns det nu en ny systemegenskap för att kontrollera cachningspolicyn för NTLM-anslutningar via HTTP. Om du definierar jdk.ntlm.cache och den utvärdas till "false" avaktiveras all cachning för NTLM-anslutningar via HTTP. Om du anger den här systemegenskapen till "false" kan det innebära vissa oönskade sidoeffekter:
- Prestanda för NTLM-anslutningar via HTTP kan försämras betydligt eftersom anslutningen måste omautentiseras för varje begäran, vilket kräver flera kommunikationsutbyten med servern.
- Inloggningsuppgifterna måste hämtas igen för varje ny begäran, vilket, beroende på om transparent autentisering är tillgängligt eller inte, och, beroende på den globala autentiserarimplementation, kan medföra att en popup visas som ber användaren om inloggningsuppgifter för varje ny begäran.
JDK-8163520 (inte allmän)
Ny version av VisualVM
VisualVM 1.3.9 publicerades den 4 oktober 2016 enligt http://visualvm.github.io/relnotes.html och har integrerats i 8u131. Se JDK-8167485

Utgångsdatum för Java

Utgångsdatum för 8u131 är den 18 juli 2017. Java går ut när en ny utgåva med korrigeringar av säkerhetsrisker blir tillgänglig. För system som inte kan nå Oracle-servrarna finns det en sekundär mekanism som upphör den här JRE:n (version 8u131) den 18 augusti 2017. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av Java om att uppdatera till den nyare versionen.

Buggfixar

Den här utgåvan innehåller korrigeringar av säkerhetsrisker. Mer information finns i Oracle Java SE Critical Patch Update Advisory. För en lista med buggfixar som är inkluderade i den här utgåvan går du till sidan buggfixar i JDK 8u131.

» Versionskommentarer till 8u131

Java 8 Update 121 (8u121)

Viktiga funktioner i versionen

IANA-data 2016i
JDK 8u121 innehåller IANA-tidszonsdata version 2016i. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Buggfix: Rullning av text med styrplatta i OS X 10.12 Sierra går mycket snabbt
Metoden MouseWheelEvent.getWheelRotation() returnerade avrundade X-/Y-deltahändelser för NSEvent i Mac OS X. I macOS Sierra 10.12 skapas mycket små X-/Y-deltahändelser för NSEvent vilket innebär att avrundning och summering av dem medför att ett stort värde returneras från MouseWheelEvent.getWheelRotation(). Med fixen JDK-8166591 ackumuleras X-/Y-deltahändelser för NSEvent och metoden MouseWheelEvent.getWheelRotation() returneras endast värden som inte är noll när det ackumulerade värdet överstiger ett tröskelvärde och ett nollvärde. Det här är kompatibelt med MouseWheelEvent.getWheelRotation()-specifikationen: "Returnerar antal 'klick' som mushjulet har roterats, som ett heltal. En partiell rotation kan inträffa om musen stöder ett hjul med hög upplösning. I så fall returnerar metoden noll tills ett fullständigt 'klick' har ackumulerats." För exakta hjulrotationsvärden använder du metoden MouseWheelEvent.getPreciseWheelRotation() i stället. Se JDK-8166591
Standardstyrkan för EC har förbättrats i JDK:t
För att förbättra standardstyrkan för EC-kryptografi har EC-nycklar som är kortare än 224 bitar avaktiverats i bearbetningen av certifieringsväg (med säkerhetsegenskapen jdk.certpath.disabledAlgorithms) och SSL/TLS-anslutningar (med säkerhetsegenskapen jdk.tls.disabledAlgorithms Security Property) i JDK:t. Applikationer kan uppdatera den här begränsningen i säkerhetsegenskaperna och tillåta kortare nyckelstorlekar om det verkligen behövs (exempel: "EC keySize < 192"). EC-kurvor som är kortare än 256 bitar har tagits bort från SSL/TLS-implementationen i JDK:t. Den nya systemegenskapen jdk.tls.namedGroups definierar en lista över aktiverade namngivna kurvor för EC-chiffersystem i prioritetsordning. Om en applikation måste anpassa de EC-kurvor som är aktiverade som standard eller kurvinställningen uppdaterar du systemegenskapen. Till exempel:
```
 jdk.tls.namedGroups="secp256r1, secp384r1, secp521r1" 
```
De EC-kurvor som är aktiverade som standard och anpassade EC-kurvor följer algoritmbegränsningarna. Anpassade EC-kurvor kan till exempel inte återaktivera de avaktiverade EC-nycklar som har definierats av Java-säkerhetsegenskaperna. Se JDK-8148516
Nytt alternativ för javadoc, --allow-script-in-comments
Verktyget javadoc kommer nu att avslå förekomster av JavaScript-kod i javadoc-dokumentationskommentarer och kommandoradsalternativ om inte alternativet --allow-script-in-comments har angetts. Med alternativet --allow-script-in-comments bevarar verktyget javadoc JavaScript-kod i dokumentationskommentarer och kommandoradsalternativ. Ett fel returneras av verktyget javadoc om JavaScript-kod hittas och kommandoradsalternativet inte har angetts.
JDK-8138725 (inte allmän)
Ökning av den minsta nyckellängden till 1024 för XML-signaturer
Det säkra valideringsläget för implementationen av XML-signaturer har förbättrats för att begränsa RSA- och DSA-nycklar som är kortare än 1024 bitar som standard eftersom de inte längre är tillräckligt säkra för att använda för digitala signaturer. Dessutom har en ny säkerhetsegenskap med namnet jdk.xml.dsig.SecureValidationPolicy lagts till i filen java.security och kan användas för att kontrollera de olika tvingade begränsningarna när det säkra valideringsläget är aktiverat. Det säkra valideringsläget aktiveras genom att ange xml-signaturegenskapen org.jcp.xml.dsig.secureValidation till true med metoden javax.xml.crypto.XMLCryptoContext.setProperty eller genom att köra koden med en SecurityManager. Om en XML-signatur genereras eller valideras med en svag RSA- eller DSA-nyckel kastades ett XMLSignatureException med meddelandet "RSA-nycklar som är kortare än 1024 bitar är förbjudna när säker validering är aktiverat" respektive "DSA-nycklar som är kortare än 1024 bitar är förbjudna när säker validering är aktiverat".
JDK-8140353 (inte allmän)
Begränsning av certifikat med DSA-nycklar som är kortare än 1024 bitar
DSA-nycklar som är kortare än 1024 bitar är inte tillräckligt kraftfulla och ska begränsas vid bygge och validering av certifieringsvägen. Dessutom har DSA-nycklar som är kortare än 1024 bitar avaktiverats som standard genom att "DSA keySize < 1024" har lagts till i säkerhetsegenskapen "jdk.certpath.disabledAlgorithms". Applikationer kan uppdatera den här begränsningen i säkerhetsegenskapen ("jdk.certpath.disabledAlgorithms") och tillåta kortare nyckelstorlekar om det behövs (exempel: "DSA keySize < 768"). JDK-8139565 (inte allmän)
Fler kontroller har lagts till i koden för kontroll av DER-kodning
Fler kontroller har lagts till i koden för kontroll av DER-kodning för att fånga olika kodningsfel. Dessutom leder nu signaturer som innehåller skapad kodning med obegränsad längd till IOException under tolkningen. Signaturer som genereras med JDK-standardleverantörerna påverkas inte av den här ändringen. JDK-8168714 (inte allmän)
Fler åtkomstbegränsningar för URLClassLoader.newInstance
Klassladdningsprogram som skapas av metoderna java.net.URLClassLoader.newInstance kan användas för att ladda klasser från en lista över angivna URL:er. Om den anropande koden inte har åtkomst till en eller flera av URL:erna och de URL-artefakter som det går att få åtkomst till inte innehåller den klass som krävs kastades ett ClassNotFoundException eller liknande. Tidigare skulle ett SecurityException ha utlöst när åtkomst till en URL nekades. Om du behöver återgå till det gamla beteendet kan du avaktivera den här ändringen genom att ange systemegenskapen jdk.net.URLClassPath.disableRestrictedPermissions. JDK-8151934 (inte allmän)
En ny konfigurerbar egenskap i logging.properties, java.util.logging.FileHandler.maxLocks
En ny konfigurerbar egenskap, "java.util.logging.FileHandler.maxLocks", har lagts till i java.util.logging.FileHandler. Den här nya loggningsegenskapen kan definieras i loggningskonfigurationsfilen och gör det möjligt att konfigurera största antal samtidiga loggfilslås som en FileHandler kan hantera. Standardvärdet är 100. I en miljö med hög samtidighet där flera (fler än 101) fristående klientapplikationer använder JDK-loggnings-API:t med FileHandler samtidigt kan det inträffa att standardgränsen på 100 uppnås vilket leder till ett fel vid försök att hämta FileHandler-fillås vilket orsakar att ett IO-undantag kastades. I sådana fall kan den nya loggningsegenskapen användas för att öka det största antalet lås innan applikationen distribueras. Om standardvärdet för maxLocks (100) inte åsidosätts ändras det inte. Se API-dokumentationen för java.util.logging.LogManager och java.util.logging.FileHandler för mer detaljer. Se JDK-8153955

Anteckningar

Förbättrat skydd för laddning av JNDI-fjärrklasser

Laddning av fjärrklasser via JNDI-objektfabriker som är lagrade i namngivnings- eller katalogtjänster är avaktiverat som standard. Om du vill aktivera laddning av fjärrklasser av RMI-registret eller tjänsteleverantören för COS-namngivning anger du följande systemegenskap till strängen "true" enligt nedan:


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

JDK-8158997 (inte allmän)

jarsigner -verbose -verify ska skriva ut de algoritmer som används för att signera jar-filen

Verktyget jarsigner har förbättrats för att visa detaljerna för de algoritmer och nycklar som används för att generera en signerad JAR-fil och tillhandahåller även en indikation om någon av dem anses som svaga.

Specifikt, när "jarsigner -verify -verbose filename.jar" anropas skrivs en separat sektion ut med information om signaturen och tidsstämpeln (om det finns någon) i den signerade JAR-filen, även om den behandlas som osignerad av någon orsak. Om någon av de algoritmer eller nycklar som används anses som svag enligt säkerhetsegenskapen jdk.jar.disabledAlgorithms får den etiketten "(svag)".

Till exempel:


 - 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

Se JDK-8163304

Kända problem

javapackager och fx\:deploy distribuerar hela JDK:t i stället för JRE:n

Det finns en känd bugg i Java Packager för Mac där hela JDK:t kan distribueras med applikationspaketet vilket resulterar i ett ovanligt stort paket. Den provisoriska lösningen är att använda paketeraralternativet -Bruntime. Exempel: -Bruntime=JavaAppletPlugin.plugin där JavaAppletPlugin.plugin för den JRE du vill paketera finns i den aktuella katalogen. Se JDK-8166835

Java-installationen utförs inte för icke-administrationsanvändare när UAC är avaktiverat

Java-installationen i Windows utförs inte utan någon varning och utan något meddelande för icke-administrationsanvändare när UAC (User Access Control) är avaktiverat. Installationsprogrammet lämnar katalogen jds<nummer>.tmp i katalogen%TEMP%.
JDK-8161460 (inte allmän)

Nya funktioner

Lade till en säkerhetsegenskap för att konfigurera läget för säker validering av XML-signaturer

En ny säkerhetsegenskap med namnet jdk.xml.dsig.secureValidationPolicy har lagts till. Du kan använda den för att konfigurera de enskilda begränsningar som tvingas när du aktiverar läget för säker validering av XML-signaturer. Standardvärdet för den här egenskapen i konfigurationsfilen java.security är:


 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

Mer information finns i definitionen för egenskapen i filen java.security. Se JDK-8151893

Konfiguration av serialiseringsfilter

Serialiseringsfiltrering har en ny mekanism där inkommande strömmar med objektserialiseringsdata kan filtreras för att förbättra både säkerheten och tillförlitligheten. Varje ObjectInputStream använder ett filter, om det är konfigurerat, på ströminnehållet under avserialiseringen. Filter anges med en systemegenskap eller en konfigurerad systemegenskap. Värdet för mönstren för "jdk.serialFilter" beskrivs i JEP 290-serialiseringsfiltrering och i <JRE>/lib/security/java.security. Filteråtgärder loggas till loggaren 'java.io.serialization', om den är aktiverad. Se JDK-8155760

Bättre kontroll av villkor för RMI

RMI-registret och DGC (Distributed Garbage Collection) använder mekanismerna i JEP 290-serialiseringsfiltrering för att förbättra tjänstetillförlitligheten. RMI-registret och DGC implementerar inbyggda vitlistefilter för de klasser som normalt förväntas användas med respektive tjänst. Du kan konfigurera fler filtermönster med en system- eller säkerhetsegenskap. Egenskapsmönstersyntaxen för "sun.rmi.registry.registryFilter" och "sun.rmi.transport.dgcFilter" beskrivs i JEP 290 och i <JRE>/lib/security/java.security. JDK-8156802 (inte allmän)

Lagt till en mekanism för att tillåta att algoritmbegränsningar inte gäller för icke-rotstandardcertifieringsinstanser

I filen java.security har en ytterligare begränsning med namnet "jdkCA" lagts till i egenskapen jdk.certpath.disabledAlgorithms. Den här begränsningen förbjuder endast den angivna algoritmen om algoritmen används i en certifikatkedja som slutar i ett markerat säkerhetsankare i nyckellagret lib/security/cacerts. Om begränsningen jdkCA inte anges är alla kedjor som använder den angivna algoritmen begränsade. jdkCA kan endast användas en gång i ett DisabledAlgorithm-uttryck. Exempel: Om du vill använda den här begränsningen på SHA-1-certifikat inkluderar du följande: SHA1 jdkCA
Se JDK-8140422

Utgångsdatum för Java

Utgångsdatum för 8u121 är den 18 april 2017. Java går ut när en ny utgåva med korrigeringar av säkerhetsrisker blir tillgänglig. För system som inte kan nå Oracles servrar avaktiverar en sekundär mekanism den här JRE-versionen (8u121) den 18 maj 2017. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av Java om att uppdatera till den nyare versionen.

Buggfixar

Den här utgåvan innehåller korrigeringar av säkerhetsrisker. Mer information finns i Oracle Java SE Critical Patch Update Advisory. För en lista över buggfixar som är inkluderade i den här utgåvan går du till sidan med buggfixar i JDK 8u121.

» Versionskommentarer till 8u121

Java 8 Update 111 (8u111)

Viktiga funktioner i versionen

IANA-data 2016f
JDK 8u111 innehåller IANA-tidszonsdata version 2016f. Mer information finns i Versioner av tidszonsdata i JRE-programvaran. Se JDK-8159684.
Certifikatändringar: ny rotcertifieringsinstans för signering av JCE-kod
Som stöd för längre nycklar och kraftfullare signaturalgoritmer har en ny rotcertifieringsinstans för signering av JCE-leverantörskod skapats och certifikatet har lagts till i Oracle-JDK:t. Nya certifikat för signering av JCE-leverantörskod som utfärdas från den här certifieringsinstansen kommer från och med nu att användas för att signera JCE-leverantörer. Som standard kommer nya begäran för signering av certifikat för JCE-leverantörskod att utfärdas från den här certifieringsinstansen.

Befintliga certifikat från den befintliga roten för signering av JCE-leverantörskod kommer att fortsätta att valideras. Den här rotcertifieringsinstansen kan komma att avaktiveras i framtiden. Oracle rekommenderar att du begär nya certifikat och signerar om befintliga leverantörs-JAR-filer. Mer information om signeringsprocessen för JCE-leverantörer finns i Hur man implementerar en leverantör i Java-kryptografiarkitekturen. JDK-8141340 (inte allmän)
Tjänster på tjänstemenyn
Under livscykelhanteringen av AWT-menykomponenter upptäcktes problem på vissa plattformar. Den här fixen förbättrar synkroniseringen av tillstånd mellan menyer och deras containrar. JDK-8158993 (inte allmän)
Avaktivering av grundläggande autentisering för HTTPS-tunnlar
I vissa miljöer kan vissa autentiseringsscheman vara oönskade när HTTPS används via en proxy. Av den anledningen har schemat för grundläggande autentisering avaktiverats som standard i Oracle Java Runtime genom att "Basic" har lagts till i nätverksegenskapen jdk.http.auth.tunneling.disabledSchemes. Nu kommer proxyer som kräver Basic-autentisering när de ställer in en tunnel för HTTPS inte längre att slutföras som standard. Om det behövs kan du återaktivera det här autentiseringsschemat genom att ta bort Basic från nätverksegenskapen jdk.http.auth.tunneling.disabledSchemes eller genom att ange en systemegenskap med samma namn till "" (tom) på kommandoraden. Dessutom kan nätverksegenskaperna jdk.http.auth.tunneling.disabledSchemes och jdk.http.auth.proxying.disabledSchemes, och systemegenskaperna med samma namn, användas för att avaktivera andra autentiseringsscheman som kan vara aktiva när du ställer in en tunnel för HTTPS respektive när du använder vanlig HTTP via en tunnel. JDK-8160838 (inte allmän)
Begränsningar för JAR-filer som har signerats med svaga algoritmer och nycklar
Den här JDK-utgåvan introducerar nya begränsningar för hur signerade JAR-filer verifieras. Om den signerade JAR-filen använder en avaktiverad algoritm eller nyckelstorlek som är mindre än den minsta längden ignorerar signaturverifieringsåtgärder signaturen och behandlar JAR-filen som om den var osignerad. Det här kan inträffa i följande typer av applikationer som använder signerade JAR-filer:
1. Appletar och Web Start-applikationer
2. Fristående applikationer och serverapplikationer där SecurityManager är aktiverat och som är konfigurerade med en policyfil som tilldelar behörigheter baserat på kodsigneraren/-signerarna för JAR-filen.

Listan över avaktiverade algoritmer kontrolleras via en ny säkerhetsegenskap, jdk.jar.disabledAlgorithms i filen java.security. Den här listan innehåller en lista över avaktiverade algoritmer och nyckelstorlekar för kryptografiskt signerade JAR-filer.

Följande algoritmer och nyckelstorlekar är begränsade i den här utgåvan:
1. MD2 (i sammandrags- eller signaturalgoritmen)
2. RSA-nycklar som är kortare än 1 024 bitar
Obs! Oracle planerar att begränsa MD5-baserade signaturer i signerade JAR-filer i CPU-utgåvan i april 2017.

Om du vill kontrollera om en svag algoritm eller nyckel har använts för att signera en JAR-fil kan du använda binärfilen jarsigner som levereras med det här JDK:t. Om du kör jarsigner -verify -J-Djava.security.debug=jar på en JAR-fil som har signerats med en svag algoritm eller nyckel skrivs mer information om den avaktiverade algoritmen respektive nyckeln ut.

Exempel: Om du vill kontrollera en JAR-fil med namnet test.jar använder du följande kommando:
jarsigner -verify -J-Djava.security.debug=jar test.jar

Om filen har signerat med en svag signaturalgoritm, som MD2withRSA, visas följande utdata:
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!

Det uppdaterade jarsigner-kommandot avslutas och följande varning skrivs till standardutdata:
"Signaturen kan inte tolkas eller verifieras. jar-filen behandlas som osignerad. jar-filen kan ha signerats med en svag algoritm som nu är avaktiverad. Om du vill ha mer information kör du jarsigner igen och aktiverar felsökning (-J-Djava.security.debug=jar)"

För att åtgärda problemet måste du signera om JAR-filen med en kraftfullare algoritm eller med en större nyckelstorlek. Alternativt så kan du återställa begränsningarna genom att ta bort de svaga algoritmerna och nyckelstorlekarna från säkerhetsegenskapen jdk.jar.disabledAlgorithms. Det alternativet rekommenderas dock inte. Innan du signerar om de påverkade JAR-filerna tar du bort de befintliga signaturerna från dem. Du kan använda verktyget zip till att göra det, enligt följande:

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

Du bör kontrollera sidan Oracle JRE and JDK Cryptographic Roadmap på http://java.com/cryptoroadmap med regelbundna intervall för mer information om planerade begränsningar för signerade JAR-filer och andra säkerhetskomponenter. Den aktuella planen är att begränsa MD5-baserade signaturer i signerade JAR-filer i CPU-utgåvan i april 2017.

Om du vill testa om JAR-filerna är signerade med MD5 lägger du till MD5 i säkerhetsegenskapen jdk.jar.disabledAlgorithms t.ex.:

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

och kör sedan jarsigner -verify -J-Djava.security.debug=jar på dina JAR-filer enligt ovan.
JDK-8155973 (inte allmän)
Varningsmeddelande har lagts till i dialogrutan för distribueringsautentiseraren
En varning har lagts till i insticksprogramsdialogrutan för autentisering där HTTP Basic-autentisering (inloggningsuppgifterna skickas okrypterade) används när en proxy används alternativt när inte SSL/TLS-protokoll används.
"VARNING: Med schemat för grundläggande autentisering överförs dina inloggningsuppgifter i klartext. Vill du verkligen göra det?"
JDK-8161647 (inte allmän)

Kända problem

Vissa händelser är inte tillgängliga i JFR-inspelningar i Windows

Följande händelser är inte tillgängliga i JFR-inspelningarna i Windows för utgåva 8u111:

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

Det beror på JDK-8063089 som introducerades i 8u111 med ändringarna för JDK-8162419. Fixen för JDK-8063089 kunde inte inkluderas i utgåva 8u111. Den kommer att vara tillgänglig i nästa BPR-bygge för 8u111 och i nästa allmänna utgåva.
JDK-8063089 (inte allmän)

NullPointerExceptions i JVM på macOS Sierra 10.12

Om en användare trycker på en låstangent (som Kommando, Skift eller Alt) i macOS Sierra 10.12 när en applet körs i webbläsaren kan felmeddelandet "Internt fel" visas. Ikonen "exec" visas också i Dock i macOS. Användaren kan stänga appleten eller köra appleten igen, utan att använda en låstangent. Se JDK-8165867.

Utgångsdatum för Java

Utgångsdatum för 8u111 är den 17 januari 2017. Java går ut när en ny utgåva med korrigeringar av säkerhetsrisker blir tillgänglig. För system som inte kan nå Oracle-servrarna finns det en sekundär mekanism som upphör den här JRE:n (version 8u111) den 17 februari 2017. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av Java om att uppdatera till den nyare versionen.

Buggfixar

» Versionskommentarer till 8u111

Java 8 Update 101 (8u101)

Viktiga funktioner i versionen

IANA-data 2016d
JDK 8u101 innehåller IANA-tidszonsdata version 2016d. Mer information finns i Versioner av tidszonsdata i JRE-programvaran. Se JDK-8151876.
Certifikatändringar
Ny DTrust-certifikat har lagts till bland rotcertifikatinstanserna
Två nya rotcertifikat har lagts till:
- 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
Se JDK-8153080

Nya Iden-certifikat har lagts till bland rotcertifikatinstanserna
Tre nya rotcertifikat har lagts till:
- 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.
Se JDK-8154757

Rotcertifikat för Comodo har tagits bort
Rotcertifikatet "UTN - DATACorp SGC" för Comodo har tagits bort från filen cacerts. Se JDK-8141540

Sonera Class1 CA" har tagits bort
Rotcertifikatet "Sonera Class1 CA" har tagits bort från filen cacerts. Se JDK-8141276.
Förbättrad åtkomstkontroll till javax.rmi.CORBA.ValueHandler
Klassen javax.rmi.CORBA.Util innehåller metoder som kan användas av "stubs" och "ties" för att utföra vanliga åtgärder. Den fungerar också som fabrik för ValueHandlers. Gränssnittet javax.rmi.CORBA.ValueHandler kan användas av tjänster som stöd för att läsa och skriva värdetyper i GIOP-strömmar. Säkerhetsfunktionerna för de här verktygen har förbättrats med den nya behörigheten java.io.SerializablePermission("enableCustomValueHanlder"). Den används för att upprätta en förtroenderelation mellan användare av API:erna javax.rmi.CORBA.Util och javax.rmi.CORBA.ValueHandler.

Den behörighet som krävs är "enableCustomValueHanlder" för SerializablePermission. Tredjepartskod som körs med en installerad SecurityManager men som inte har den nya behörigheten när den anropar Util.createValueHandler() utförs inte, med ett AccessControlException.

Det här behörighetskontrollbeteendet kan åsidosättas i JDK8u och tidigare utgåvor genom att definiera systemegenskapen "jdk.rmi.CORBA.allowCustomValueHandler".

Externa applikationer som explicit anropar javax.rmi.CORBA.Util.createValueHandler kräver en konfigurationsändring för att fungera när en SecurityManager är installerad och när inget av följande två krav är uppfyllda:
1. java.io.SerializablePermission("enableCustomValueHanlder") ges inte av SecurityManager.
2. För applikationer som körs i JDK8u och tidigare är systemegenskapen "jdk.rmi.CORBA.allowCustomValueHandler" antingen inte definierad eller är definierad att vara lika med "false" (skiftlägesokänsligt).
Stavfelet "enableCustomValueHanlder" kommer att korrigeras i utgåvor i oktober 2016. I de utgåvorna och i framtida JDK-utgåvor kommer "enableCustomValueHandler" att vara rätt värde att använda för SerializationPermission.
JDK-8079718 (inte allmän)
Stöd för att ange hashningsalgoritm för tidsstämplar har lagts till i jarsigner
Det nya alternativet -tsadigestalg har lagts till i jarsigner för att ange den hashningsalgoritm för meddelanden som används för att generera det meddelandeavtryck som ska skickas till TSA-servern. I äldre JDK-utgåvor var den hashningsalgoritm som användes för meddelanden SHA-1. Om det här nya alternativet inte anges används SHA-256 för JDK 7-uppdateringar och senare versioner av JDK-familjen. I JDK 6-uppdateringar förblir SHA-1 standard men en varning skrivs till standardutdataströmmen. Se JDK-8038837
MSCAPI KeyStore kan hantera certifikat med samma namn
Java SE KeyStore tillåter inte att certifikat har samma alias. I Windows kan flera certifikat som lagras i ett nyckellager ha icke-unika användarvänliga namn. Fixen för JDK-6483657 gör det möjligt att hantera den typen av certifikat med icke-unika namn via Java-API:t genom att på konstgjord väg göra de synliga aliasen unika. Den här fixen innebär inte att det går att skapa certifikat med samma namn med Java-API:t. Den innebär endast att du kan hantera certifikat med samma namn som har lagts till i nyckellagret av tredjepartsverktyg. Oracle rekommenderar fortfarande att du inte använder flera certifikat med samma namn. I synnerhet kommer inte följande mening att tas bort från Java-dokumentationen:
"För att undvika problem rekommenderar Oracle att du inte använder alias i ett KeyStore där endast skiftläget är olika."
Se JDK-6483657.
Metoder i API:t Deployment Toolkit installerar inte längre JRE:n
Metoderna installLatestJRE() och installJRE(requestedVersion) från deployJava.js och metoden install() från dtjava.js i API:t Deployment Toolkit installerar inte längre JRE:n. Om en användares version av Java är lägre än säkerhetsutgångsvärdet omdirigeras användaren till java.com för att hämta en uppdaterad JRE. JDK-8148310 (inte allmän)
DomainCombiner kontrollerar inte längre exekveringspolicyn för statiska ProtectionDomain-objekt vid kombination av ProtectionDomain-objekt
Applikationer som använder statiska ProtectionDomain-objekt (som har skapats med konstruktorn med två argument) med en otillräcklig uppsättning med behörigheter kan nu få ett AccessControlException med den här fixen. Du måste antingen ersätta de statiska ProtectionDomain-objekten med dynamiska (med konstruktorn med 4 argument) vars behörighetsuppsättning expanderas av den aktuella policyn eller konstruera det statiska ProtectionDomain-objektet med alla behörigheter som krävs. JDK-8147771 (inte allmän)

Kända problem

JRE 8u101 känns inte igen av Internet Explorer (IE) vid användning av ett statiskt klass-id

När ett statiskt klass-id används för att starta en applet- eller Web Start-applikation vid användning av JRE 8u101 visas en oönskad dialogruta för användare om att de antingen måste använda den senaste JRE:n eller avbryta starten även när de har installerat och använder den senaste JRE:n (JRE 8u101). Det här specifika fallet gäller endast för Windows och IE.

Oracle rekommenderar inte att du använder ett statiskt klass-id för att välja JRE-version (sedan JDK 5u6 i december 2005) enligt http://www.oracle.com/technetwork/java/javase/family-clsid-140615.html.

Som en provisorisk lösning på det här problemet kan användare göra någon av följande två saker:

Klicka på Starta med den senaste versionen (8u101) och ignorera varningen.
Installera JRE 8u102 i stället för JRE 8u101 för att undvika problemet.

För att undvika det här problemet kan utvecklare göra något av följande två saker:

Använda ett dynamiskt klass-id i stället för ett statiskt klass-id.
Använda java_version när de använder en HTML-applet eller en JNLP-deskriptor när de använder JNLP.

JDK-8147457 (inte allmän)

Buggfixar

Utgångsdatum för Java

Utgångsdatum för 8u101 är den 19 oktober 2016. Java går ut när en ny utgåva med korrigeringar av säkerhetsrisker blir tillgänglig. För system som inte kan nå Oracles servrar upphör en sekundär mekanism den här JRE-versionen (version 8u101) den 19 november 2016. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av Java om att uppdatera till den nyare versionen.

» Versionskommentarer till 8u101

Java 8 Update 91 (8u91)

Viktiga funktioner i versionen

IANA-data 2016a
JDK 8u91 innehåller IANA-tidszonsdata version 2016a. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Buggfix: Borttagning av appletstarttid har korrigerats
JDK-8080977 introducerade en fördröjning vid appletstart. Den här fördröjningen inträffar endast i IE och är cirka 20 sekunder. JDK-8136759 tog bort den här fördröjningen. Se JDK-8136759
Buggfix: En kontroll av nyckelstyrka utförs vid generering av DSA-signaturer
För generering av signaturer, om säkerhetsstyrkan för sammandragsalgoritmen är svagare än säkerhetsstyrkan för den nyckel som används för att signera signaturen (t.ex. om du använder DSA-nycklar med (2048, 256) bitar med signaturen SHA1withDSA) utförs inte åtgärden med felmeddelandet "Säkerhetsstyrkan för SHA1-sammandragsalgoritmen är inte tillräcklig för den här nyckelstorleken". JDK-8138593 (inte allmän)
Buggfix: Problem med Live Connect i Firefox 42
Eftersom anrop från JavaScript till Java medför att webbläsaren slutar svara bearbetas inte den typen av anrop när Java-insticksprogrammet startas från plugin-container.exe (standardbeteende för Firefox 42) och appletstatusen inte är "Ready" (2). Om appleten inte är klar (dvs. om statusen inte är 2) körs inte den faktiska Java-metoden och null returneras.

Om insticksprogrammet startas från plugin-container.exe bör du inte använda anrop från JavaScript till Java som kan ta längre tid än 11 sekunder (standardvärdet för dom.ipc.plugins.hangUITimeoutSecs) att slutföra, och du bör inte heller visa en modal dialogruta under anrop från JavaScript till Java. Om du gör det kan huvudwebbläsartråden blockeras, vilket kan medföra att webbläsaren kraschar och att insticksprogrammet avslutas.

Provisorisk lösning för Firefox 42: du kan ange dom.ipc.plugins.enabled=false. Nackdelen med den här provisoriska lösningen är att den ändrar inställningen för alla insticksprogram. JDK-8144079 (inte allmän)
Buggfix: Nytt attribut för JMX-/RMI-/JRMP-servrar för att ange en lista över klassnamn att använda vid avserialisering av serverinloggningsuppgifter
Ett nytt javaattribut har definierats för miljön för att tillåta att en JMX-/RMI-/JRMP-server anger en lista över klassnamn. De här namnen motsvarar omfattningen för de klassnamn som förväntas av servern vid avserialisering av inloggningsuppgifter. Om de förväntade inloggningsuppgifterna till exempel var
```
 List<string>
```
motsvarar omfattningen alla konkreta klasser som skulle kunna förväntas i serieform av en lista över strängar.

Som standard används det här attributet endast av standardagenten med följande:
```
 { "[Ljava.lang.String;", "java.lang.String" } 
```
Endast uppställningar med strängar och strängar accepteras vid avserialiseringar av inloggningsuppgifterna. Attributnamnet är:
```
"jmx.remote.rmi.server.credential.types" 
```
Följande är ett exempel på en användare som startar en server med de angivna inloggningsuppgiftsklassnamnen:
```
 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); 
```
Den nya funktionen ska användas genom att ange följande:
"jmx.remote.rmi.server.credential.types"

JDK-8144430 (inte allmän)
Buggfix: Signaturalgoritmen MD5withRSA har avaktiverats i leverantören JSSE
Signaturalgoritmen MD5withRSA anses nu som osäker och ska inte längre användas. Därför har MD5withRSA avaktiverats som standard i Oracle JSSE-implementationen genom att lägga till "MD5withRSA" till säkerhetsegenskapen "jdk.tls.disabledAlgorithms". Nu accepteras varken TLS-handskakningsmeddelanden eller X.509-certifikat som har signerats med algoritmen MD5withRSA som standard. Den här ändringen utökar den tidigare begränsningen för MD5-baserade certifikat ("jdk.certpath.disabledAlgorithms") så att den även inkluderar handskakningsmeddelanden i TLS version 1.2. Om det behövs kan algoritmen återaktiveras genom att ta bort "MD5withRSA" från säkerhetsegenskapen "jdk.tls.disabledAlgorithms". JDK-8144773 (inte allmän)
Buggfix: Nya certifikat har lagts till rotcertifieringsinstanser
Åtta nya rotcertifikat har lagts till:
- 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
Se JDK-8145954 och JDK-8145955.

Anteckningar

Borttagning av statiska JRE:er
Java-installationsprogram för Windows som publicerades före version 8u91 tog inte bort statiskt installerade JRE:er som standard. För att ta bort JRE:er som hade installerats statiskt var användare tvungna att manuellt välja de JRE:erna i användargränssnittet för installationsprogrammet för Java. Nu, i Java-utgåva 8u91 och senare, tas JRE:er som har installerats statiskt bort automatiskt om de är lägre än säkerhetsutgångsvärdet. Mer information om statiska installationer finns i JRE-konfiguration (Java Runtime Environment).

Utgångsdatum för Java

Utgångsdatum för 8u91 är den 19 juli 2016. Java går ut när en ny utgåva med korrigeringar av säkerhetsrisker blir tillgänglig. För system som inte kan nå Oracle-servrarna finns det en sekundär mekanism som upphör den här JRE:n (version 8u91) den 19 augusti 2016. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av Java om att uppdatera till den nyare versionen.

Buggfixar

» Versionskommentarer till 8u91

Java 8 Update 77 (8u77)

Viktiga funktioner i versionen

IANA-data 2016a
JDK 8u77 innehåller IANA-tidszonsdata version 2016a. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.

Utgångsdatum för Java

Utgångsdatum för 8u77 är den 19 april 2016. Java går ut när en ny utgåva med korrigeringar av säkerhetsrisker blir tillgänglig. För system som inte kan nå Oracles servrar upphör en sekundär mekanism den här JRE:n (version 8u77) den 19 maj 2016. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av Java om att uppdatera till den nyare versionen.

Anteckningar

Denna säkerhetsavisering (8u77) är baserad på den tidigare 8u74 PSU-utgåvan. Alla användare av tidigare JDK 8-utgåvor bör uppdatera till den här utgåvan. Mer information om skillnaderna mellan kritiska programfixuppdateringar (CPU) och PSU-uppdateringar (uppdateringar av programfixuppsättningar) finns i Java CPU- och PSU-utgåvor förklarat.

Demo-, exempel- och dokumentationspaketen för 8u77 påverkas inte av säkerhetsaviseringen för CVE-2016-0636, så demo-, exempel- och dokumentationspaketen för 8u73 är fortsatt de mest uppdaterade versionerna fram till aprilutgåvan av kritiska programfixuppdateringar.

Buggfixar

Den här utgåvan innehåller korrigeringar av säkerhetsrisker. Mer information finns i Oracle Java SE Critical Patch Update Advisory.

» Versionskommentarer till 8u77

Java 8 Update 73 (8u73)

Viktiga funktioner i versionen

IANA-data 2015g
JDK 8u71 innehåller IANA-tidszonsdata version 2015g. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.

Utgångsdatum för Java

Utgångsdatum för 8u73 är den 19 april 2016. Java går ut när en ny utgåva med korrigeringar av säkerhetsrisker blir tillgänglig. För system som inte kan nå Oracles servrar avaktiverar en sekundär mekanism den här JRE:n (8u73) den 19 maj 2016. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av Java om att uppdatera till den nyare versionen.

Anteckningar

Oracle rekommenderar att Java-användare som har laddat ned påverkade versioner och planerar att utföra installationer med de nedladdade versionerna makulerar de nedladdningarna. Java-användare som har installerat Critical Patch Update-versionen från januari 2016 av Java SE 6, 7 eller 8 behöver inte utföra någon åtgärd. Java-användare som inte har installerat Critical Patch Update-versionen från januari 2016 av Java SE 6, 7 eller 8 ska uppgradera till Java SE 6-, 7- eller 8-versionen från säkerhetsaviseringen för CVE-2016-0603.

Exemplen och dokumentationspaketen för 8u73 påverkas inte av säkerhetsaviseringen för CVE-2016-0603 vilket innebär att exemplen och dokumentationspaketen för version 8u71 förblir aktuella tills Critical Patch Update-utgåvan i april.

Buggfixar

Den här utgåvan innehåller korrigeringar av säkerhetsrisker. Mer information finns i Oracle Java SE Critical Patch Update Advisory. 8u73 innehåller inte de PSU-byggen som finns i 8u72. Kunder som kräver de buggfixar som finns i 8u72 ska uppdatera till 8u74 i stället för till 8u73.

» Versionskommentarer till 8u73

Java 8 Update 71 (8u71)

Viktiga funktioner i versionen

IANA-data 2015g
JDK 8u71 innehåller IANA-tidszonsdata version 2015g. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Buggfix: All information visas inte när du kör jps som root
Efter att buggen i JDK-8050807 har fixats (fixad i 8u31, 7u75 och 6u91) visas inte all information från Java-processer som har startats av andra användare när du kör jps som root på vissa system. Det här har nu åtgärdats. Se JDK-8075773.
Buggfix: Installationsprogram verkar ha avstannat i ESC-konfigurationer
Om du använde Internet Explorer Enhance Security Configuration (ESC) på Windows Server 2008 R2 kan det ha uppstått problem när du försökte installera Java i det interaktiva läget. Det här problemet har lösts i utgåva 8u71. När du kör installationsprogram i det interaktiva läget verkar de inte längre ha avstannat i ESC-konfigurationer. Se JDK-8140197.
Buggfix: Problem med PBE-algoritmer som använder AES-kryptot har korrigerats
Ett fel har korrigerats för PBE som använder 256-bitars AES-chiffer så att den härledda nyckeln kan vara en annan och inte samma som nycklar som tidigare har härletts från samma lösenord. JDK-8138589 (inte allmän).
Buggfix: Standardgräns har lagts till för största entitetsstorlek för XML
En standardgräns för största entitetsstorlek har lagts till. Mer information XML-bearbetningsgränser finns i Java-självstudierna om bearbetningsgränser. JDK-8133962 (inte allmän)
Buggfix: Problem med dokumentationen för MSI-växeln 'REMOVEOLDERJRES' för Enterprise har korrigerats
MSI-dokumentationen för Enterprise listar konfigurationsalternativ. Alternativet REMOVEOLDERJRES som används för att avinstallera äldre JRE:er saknades. Det här alternativet har lagts till med följande beskrivning:
Om det här alternativet anges till 1 tas äldre utgåvor av det JRE som är installerat på systemet bort.
Standard: Med 0 tas inga äldre JRE:er bort
JDK-8081237 (inte allmän)

Utgångsdatum för Java

Utgångsdatum för 8u71 är den 19 april 2016. Java går ut när en ny utgåva med korrigeringar av säkerhetsrisker blir tillgänglig. För system som inte kan nå Oracles servrar upphör en sekundär mekanism den här JRE:n (8u71) den 19 maj 2016. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av Java om att uppdatera till den nyare versionen.

Buggfixar

Den här utgåvan innehåller korrigeringar av säkerhetsrisker. Mer information finns i Oracle Java SE Critical Patch Update Advisory.

En lista över buggfixar som är inkluderade i den här utgåvan finns på sidan med buggfixar i JDK 8u71.

» Versionskommentarer till 8u71

Java 8 Update 66 (8u66)

Viktiga funktioner i versionen

8u66 bygge 18 korrigerar ett problem i Firefox.

Buggfix: _releaseObject anropas från fel tråd
En ändring som nyligen gjordes i Firefox medförde att anropet till _releaseObject utfördes från en annan tråd än huvudtråden. Det här kan orsaka ett tillstånd som kan medföra att webbläsaren kraschar. Det här har åtgärdats i bygge 18 för 8u66. Mer information finns i Bugs@Mozilla 1221448. Se JDK-8133523.

Java-insticksprogram fungerar inte i Firefox när Java har installerats

Firefox 42 kan krascha när du försöker köra Java-insticksprogrammet. Olika provisoriska lösningar finns i de vanliga frågorna. Se JDK-8142908 (inte allmän).

Utgångsdatum för Java

Utgångsdatum för 8u66 är den 19 januari 2016. Java går ut när en ny utgåva med korrigeringar av säkerhetsrisker blir tillgänglig. För system som inte kan nå Oracle-servrarna finns det en sekundär mekanism som upphör den här JRE:n (version 8u66) den 19 februari 2016. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av Java om att uppdatera till den nyare versionen.

Buggfixar

Den här utgåvan innehåller korrigeringar av säkerhetsrisker. Mer information finns i Oracle Java SE Critical Patch Update Advisory.

För en lista över buggfixar som är inkluderade i den här utgåvan går du till sidan med buggfixar i JDK 8u66.

» Versionskommentarer till 8u66

Java 8 Update 65 (8u65)

Viktiga funktioner i versionen

IANA-data 2015f
JDK 8u65 innehåller IANA-tidszonsdata version 2015f. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Stöd för ISO 4217-tabellen med koder för aktuella valutor (A.2)
Den här förbättringen lägger till stöd för tabell A.2 för ISO 4217 med valutakoder. Tidigare fanns det endast stöd i JDK:t för de valutor som var angivna i tabell A.1. Se JDK-8074350.
Buggfix: [mac osx] Uppdatering av installerade JRE AU-klienter till NEXTVER i OS X 10.11 utförs inte
Ett nytt installationsprogram introduceras i utgåva 8u65 för att uppdatera OS X-användare till den senaste versionen. Installationsprogrammet används både för schemalagda och för manuella uppdateringar, och paket är tillgängliga på java.com och OTN. Om du har kompatibilitetsproblem med det nya installationsprogrammet kan du ladda ned och installera installationsprogrammet med ".pkg" som är tillgängligt från My Oracle Support.
Buggfix: HotSpot ska använda PICL-gränssnittet för att hämta cacheradsstorlek i SPARC
Biblioteket libpicl krävs nu i Solaris/SPARC för att fastställa storleken på cacherader. Om biblioteket inte finns eller om PICL-tjänsten inte är tillgängligt visar JVM:en en varning och kompileringsoptimeringar som använder BIS-instruktionen (Block Initializing Store) avaktiveras. Se JDK-8056124.
Buggfix: dns_lookup_realm ska ha värdet false som standard
Inställningen dns_lookup_realm i Kerberos-filen krb5.conf är false som standard. Se JDK-8080637.
Buggfix: Förladdning av libjsig.dylib orsakar dödläge när signal() anropas
Applikationer måste förladda biblioteket libjsig för att aktivera signalkedjelänkning. Tidigare, i OS X, efter att libjsig.dylib hade förladdats, orsakade alla anrop från inbyggd kod till signal() ett dödläge. Det här har korrigerats. Se JDK-8072147.
Buggfix: Bättre gruppdynamik
I implementationen av SSL/TLS/DTLS för OpenJDK (leverantören SunJSSE) används säkra Diffie-Hellman-primtalsgrupper som standard. Du kan använda anpassade Diffie-Hellman-grupper via säkerhetsegenskapen jdk.tls.server.defaultDHEParameters.
Buggfix: VM:en kraschar när klassen omdefinieras med Instrumentation.redefineClasses
JVM:en kunde krascha när en klass omdefinierades med Instrumentation.redefineClasses(). Kraschen kan antingen vara ett segmenteringsfel vid SystemDictionary::resolve_or_null eller ett internt fel med ett meddelande om att det finns en tagg som inte matchar i lösningsfeltabellen. Det här har nu åtgärdats. Se JDK-8076110.

Anteckningar

När du kör OS X 10.11 El Capitan och SIP är aktiverat kan vissa miljövariabler som är avsedda för att felsöka applikationer, som DYLD_LIBRARY_PATH tas bort från miljön när du kör Java från kommandoraden eller när du dubbelklickar på en JAR-fil. Applikationer ska inte använda de här variablerna i en produktionsmiljö, de är endast avsedda för felsökning under utvecklingen.

MD5 får inte användas för digitala signaturer när kollisionsresistens krävs. För att förhindra användning av MD5 som algoritm för digitala signaturer under X.509-certifikatåtgärder har MD5 lagts till säkerhetsegenskapen jdk.certpath.disabledAlgorithms. För de applikationer som fortfarande använder ett certifikat som är signerat med MD5 måste du uppgradera det svaga certifikatet så snart som möjligt.

Kända problem

[macosx] Problem med hjälpmedelsfunktioner (a11y) på sponsorerbjudandeskärmar
Om du använder tangentbordet till att få åtkomst till gränssnitten i installationsprogrammet för Java kan du inte få åtkomst till hyperlänkar och kryssrutor på skärmarna med erbjudanden om tilläggsprogramvara. Som en provisorisk lösning för att ange inställningar som är relaterade till tilläggsprogramvara i användargränssnittet kan du avaktivera den typen av erbjudanden genom att avaktivera dem i kontrollpanelen för Java eller genom att överföra SPONSORS=0 via kommandoraden. Mer information finns i Frågor och svar om att installera Java utan sponsorerbjudanden. Se JDK-8061886 (inte allmän).

Utgångsdatum för Java

Utgångsdatum för 8u65 är den 19 januari 2016. Java går ut när en ny utgåva med korrigeringar av säkerhetsrisker blir tillgänglig. För system som inte kan nå Oracle-servrarna finns det en sekundär mekanism som upphör den här JRE:n (version 8u65) den 19 februari 2016. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av Java om att uppdatera till den nyare versionen.

Buggfixar

Den här utgåvan innehåller korrigeringar av säkerhetsrisker. Mer information finns i Oracle Java SE Critical Patch Update Advisory.

För en lista med buggfixar som är inkluderade i den här utgåvan går du till sidan med buggfixar i JDK 8u65.

» Versionskommentarer till 8u65

Java 8 Update 60 (8u60)

Viktiga funktioner i versionen

IANA Data 2015e
JDK 8u60 innehåller IANA-tidszonsdata version 2015e. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Buggfix: dns_lookup_realm ska ha värdet false som standard
Inställningen dns_lookup_realm i filen Kerberos' krb5.conf ska ha värdet false som standard. Se 8080637.
Buggfix: Avaktivera RC4-chiffersystem
RC4-baserade TLS-chiffersystem (t.ex. TLS_RSA_WITH_RC4_128_SHA) anses nu vara komprometterade och ska inte längre användas (se RFC 7465). Därför har RC4-baserade TLS-chiffersystem avaktiverats som standard i Oracle JSSE-implementationen genom att lägga till "RC4" till säkerhetsegenskapen "jdk.tls.disabledAlgorithms" och genom att ta bort dem från listan över de chiffersystem som är aktiverade som standard. De här chiffersystemen kan återaktiveras genom att ta bort "RC4" från säkerhetsegenskapen "jdk.tls.disabledAlgorithms" i filen java.security eller genom att dynamiskt anropa Security.setProperty() samt lägga till dem i listan över aktiverade chiffersystem med metoderna SSLSocket/SSLEngine.setEnabledCipherSuites(). Du kan också använda kommandoradsalternativet -Djava.security.properties till att åsidosätta säkerhetsegenskapen jdk.tls.disabledAlgorithms. Till exempel:
java -Djava.security.properties=my.java.security ...
där my.java.security är en fil som innehåller egenskapen utan RC4:
jdk.tls.disabledAlgorithms=SSLv3
Även med detta alternativ inställt från kommandoraden behöver RC4-baserade chiffersviter läggas till på nytt i den aktiverade chiffersvitlistan genom att använda metoderna SSLSocket/SSLEngine.setEnabledCipherSuites(). Se 8076221.
Buggfix: Stöd för avkänning av nyckellagertyp för JKS- och PKCS12-nyckellager
Kompatibilitetsläge för nyckellager: För stöd av interoperabilitet stöder Java-nyckellagertypen JKS nu kompatibilitetsläget för nyckellager som standard. Det här läget gör det möjligt för JKS-nyckellager att öppna både JKS- och PKCS12-filformat. Om du vill avaktivera kompatibilitetsläget för nyckellager anger du säkerhetsegenskapen keystore.type.compat till strängvärdet false. Se 8062552.
Buggfix: Gör osäkra övervakningsmetoder i JDK 8u-utgåvan inaktuella
Metoderna monitorEnter monitorExit och tryMonitorEnter i sun.misc.Unsafe är markerade som inaktuella i JDK 8u60 och kommer att tas bort i en framtida utgåva. De här metoderna används inte i JDK och används mycket sällan utanför JDK. Se 8069302.
Buggfix: Extrahera JFR-inspelning från kärnfilen med SA
DumpJFR är ett Serviceability Agent-baserat verktyg som kan användas till att extrahera JFR-data (Java Flight Recorder) från kärnfilerna och pågående Hotspot-processer. DumpJFR kan användas i en av följande metoder:
- Bifoga DumpJFR till en aktiv process:
  
  The embedded asset does not exist:
  Asset Type: jWidget_C
  Asset Id: 1371164883097
  PAGENAME: JCOM/jWidget_C/Raw_HTML/Display
- Bifoga DumpJFR till en kärnfil:
  
  The embedded asset does not exist:
  Asset Type: jWidget_C
  Asset Id: 1371164883117
  PAGENAME: JCOM/jWidget_C/Raw_HTML/Display
DumpJFR-verktyget dumpar JFR-data till en fil med namnet recording.jfr i den aktuella arbetsmappen. See 8065301 (inte allmän).
Buggfix: Lokala variabler med namnet 'enum' leder till falska kompilatorkrascher
javac-parsern tolkar lokala variabler med namnet 'enum' felaktigt. Det leder till falska krascher när ett program som innehåller sådana lokala variabler kompileras med en 'source'-flagga som motsvarar en version där enum-konstruktioner inte är tillgängliga (t.ex. '-source 1.4'). Se 8069181.

Java Development Kit för ARM utgåva 8u60

Denna utgåva inkluderar Java Development Kit för ARM utgåva 8u60 (JDK 8u60 för ARM). For information om ARM-enhetssupport, se sidan JDK för ARM-nedladdningar. För systemkrav, installationsinstruktioner och felsökningstips, se sidan Installationsinstruktioner.

Begränsning: Support för spårning av inbyggt minne är begränsat i JDK för ARM. Javakommandoradsalternativet XX:NativeMemoryTracking=detail kan inte användas för ARM-mål (ett felmeddelande visas för användaren). Använd istället följande alternativ:
XX:NativeMemoryTracking=summary

Dokumentationsuppdateringar p.g.a. Nashorn-förbättringar

JDK 8u60 inkluderar nya Nashorn-förbättringar. Därför bör följande dokumentationsändringarna läsas i samband med den aktuella Nashorn-dokumentationen:

Tillägg: I föregående sektion nämnde vi att varje JavaScript-objekt implementerar gränssnittet java.util.Map när det exponeras för Java-API:er. Det här gäller även för JavaScript-uppställningar. Dock är det här ofta inte den funktionalitet som önskas eller förväntas när Java-koden förväntar sig JSON-tolkade objekt. Java-bibliotek som hanterar JSON-tolkade objekt förväntar sig ofta att uppställningar ska exponera gränssnittet java.util.List istället. Om du behöver exponera JavaScript-objekt så att uppställningar exponeras som listor och inte mappningar kan du använda funktionen Java.asJSONCompatible(obj), där obj är roten för JSON-objektträdet.
Rättelse: Varningen som omnämns i slutet av sektionen Mappa datatyper gäller inte längre. Nashorn säkerställer att interna JavaScript-strängar konverteras till java.lang.String när de exponeras externt.
Rättelse: Påståendet i sektionen Mappa datatyper som nämner att "t.ex. så måste uppställningar konverteras explicit..." är felaktigt. Uppställningar konverteras automatiskt till Java-uppställningstyper som java.util.List java.util.Collection java.util.Queue och java.util.Deque o.s.v.

Ändringar i Deployment Rule Set v1.2

JDK 8u60 implementerar DRS 1.2 (Deployment Rule Set ) som inkluderar följande ändringar:

Lägg till elementet "checksum" som underelement till "id". Det gör att osignerade jar-arkiv kan identifieras av SHA-256-kontrollsumman för den okomprimerade formen av jar-arkivet:
- Elementet "checksum" matchar endast osignerade jar-arkiv och det givna hashvärdet jämförs endast med den okomprimerade formen av jar-arkivet.
- Elementet "checksum" har, liksom elementet "certificate", två argument, "hash" och "algorithm", men till skillnad från elementet "certificate" är "SHA-256" det enda värdet som stöds för "algorithm". Alla andra värden som anges ignoreras.
Låt elementet "message" tillämpas på alla regeltyper när det tidigare bara tillämpades på en blockeringsregel:
- I en körningsregel öppnar ett message-underelement en meddelandedialogruta. Utan en körningsregel är standardfunktionaliteten att en certifikat- eller osignerad dialogruta visas. Meddelandet kommer att visas i meddelandedialogrutan.
- I en standardregel visas meddelandet endast om standardåtgärden är att blockera. I sådana fall inkluderas meddelandet i blockeringsdialogrutan.
Visning av "customer"-block i Javakonsolen, spårningsfiler och Java Usage Tracker-poster.
- Innan DRS 1.2 kunde "customer"-element inkluderas (tillsammans med eventuella underelement) i filen ruleset.xml. Det här elementet och dess underelement ignoreras. I DRS 1.2 ignoreras fortfarande elementen funktionsmässigt. Dock:
  - När filen ruleset.xml tolkas kommer alla "customer"-block att visas (echo) på Javakonsolen och spårningsfilen för distribuering (om konsolen och spårningsfunktionen har aktiverats).
  - När en regel används kommer alla "customer"-poster inkluderade i den regeln att läggas till i JUT-posten (Java Usage Tracker) om JUT har aktiverats.

Till följd av ovannämnda ändringar är DTD:n för DRS 1.2 följande:
The embedded asset does not exist:
Asset Type: jWidget_C
Asset Id: 1385352043373
PAGENAME: JCOM/jWidget_C/Raw_HTML/Display

Utgångsdatum för Java

Utgångsdatum för 8u60 är den 20 oktober 2015. Java går ut när en ny utgåva med korrigeringar av säkerhetsrisker blir tillgänglig. För system som inte kan nå Oracles servrar avaktiverar en sekundär mekanism den här JRE-versionen (version 8u60) den 20 november 2015. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av Java om att uppdatera till den nyare versionen.

Buggfixar

För en lista över buggfixar som är inkluderade i den här utgåvan går du till sidan buggfixar i JDK 8u60.

» Versionskommentarer till 8u60

Java 8 Update 51 (8u51)

Viktiga funktioner i versionen

IANA-data 2015d
JDK 8u51 innehåller IANA-tidszonsdata för version 2015d. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Buggfix: Tillägg av nya Comodo-rotcertifikat till rotcertifieringsinstanser
Fyra nya rotcertifikat har lagts till för Comodo:
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
Se JDK-8077997 (inte allmän).
Buggfix: Tillägg av nya GlobalSign-rotcertifikat till rotcertifieringsinstanser
Två nya rotcertifikat har lagts till för GlobalSign:
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
Se JDK-8077995 (inte allmän).
Buggfix: Tillägg av Actalis till rotcertifieringsinstanser
Tillägg av ett nytt rotcertifikat:
Actalis Authentication Root CA alias: actalisauthenticationrootca DN: CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT
Se JDK-8077903 (inte allmän).
Buggfix: Tillägg av ett nytt Entrust ECC-rotcertifikat
Tillägg av ett nytt rotcertifikat:
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
Se JDK-8073286 (inte allmän).
Buggfix: Tog bort gamla Valicert-klass 1- och Valicert-klass 2-policyrotcertifikat
Tog bort två rotcertifikat med 1024-bitarsnycklar:
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
Se JDK-8077886 (inte allmän).
Buggfix: Tog bort gamla Thawte-rotcertifikat
Tog bort två rotcertifikat med 1024-bitarsnycklar:
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
Se JDK-8074423 (inte allmän).
Buggfix: Tog bort fler gamla Verisign-, Equifax- och Thawte-rotcertifikat
Tog bort fem rotcertifikat med 1024-bitarsnycklar:
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
Se JDK-8076202 (inte allmän).
Buggfix: Tog bort rotcertifikat för TrustCenter-certifieringsinstanser från cacerts
Tog bort tre rotcertifikat:
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
Se JDK-8072958 (inte allmän).
Buggfix: Angav RC4 som inaktuellt i leverantören SunJSSE
RC4 anses nu som ett svagt chiffer. Servrar bör inte välja RC4 om det inte finns en bättre kandidat i de klientbegärda chiffersystemen. En ny säkerhetsegenskap, jdk.tls.legacyAlgorithms har lagts till för att definiera de äldre algoritmerna i Oracle JSSE-implementationen. RC4-relaterade algoritmer har lagts till i listan över äldre algoritmer. Se JDK-8074006 (inte allmän).
Buggfix: Förbjöd RC4-chiffersystem
RC4 anses nu som ett chiffer som inte är säkert. RC4-chiffersystem har tagits bort från listan över chiffersystem som är aktiverade som standard både för klienter och servrar i Oracle JSSE-implementationen. De här chiffersystemet kan fortfarande aktiveras av metoderna SSLEngine.setEnabledCipherSuites() och SSLSocket.setEnabledCipherSuites(). Se JDK-8077109 (inte allmän).
Buggfix: Förbättrad certifikatkontroll
Med den här fixen utför inte JSSE-slutpunktsidentifiering någon omvänd uppslagning av namn för IP-adresser som standard i JDK:t. Om en applikation behöver utföra omvänd uppslagning av namn för rå-IP-adresser i SSL/TLS-anslutningar och påträffar ett kompatibilitetsproblem med slutpunktsidentifieringen kan systemegenskapen "jdk.tls.trustNameService" användas för att aktivera omvänd uppslagning av namn. Obs! Om namntjänsten inte är tillförlitlig löper du en risk att bli utsatt för MITM-attacker när du aktiverar omvänd uppslagning av namn. Se JDK-8067695 (inte allmän).

Utgångsdatum för Java

Utgångsdatum för 8u51 är den 20 oktober 2015. Java går ut när en ny utgåva med korrigeringar av säkerhetsrisker blir tillgänglig. För system som inte kan nå Oracles servrar upphör en sekundär mekanism den här JRE-versionen (version 8u51) den 20 november 2015. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av Java om att uppdatera till den nyare versionen.

Buggfixar

Den här utgåvan innehåller korrigeringar av säkerhetsrisker. Mer information finns i Oracle Java SE Critical Patch Update Advisory.

För en lista med buggfixar som är inkluderade i den här utgåvan går du till sidan buggfixar i JDK 8u51.

» Versionskommentarer för 8u51

Java 8 Update 45 (8u45)

Viktiga funktioner i versionen

IANA-data 2015a
JDK 8u45 innehåller IANA-tidszonsdata version 2015a. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Buggfix: Förbättra hantering av jar-filer. Från och med utgåva JDK 8u45 tillåter inte längre verktyget jar sökvägskomponenten med inledande snedstreck ("/") och två punkter ("..") i filnamnet för zip-posten vid skapande av nya jar-filer eller vid extrahering från zip- eller jar-filer. Om det behövs ska det nya kommandoradsalternativet "-P" användas explicit för att bevara sökvägskomponenten med två punkter och/eller absolut sökväg. Se 8064601 (inte allmän).
Buggfix: jnlp-app med kapslad "resource"-sektion utförs inte med NPE vid laddning i jre8u40. En jnlp-applikation med kapslade -taggar i en <java>-eller -tagg kan kasta ett NPE. Problemet är nu åtgärdat. Taggen ska endast användas om <java> faktiskt används. Se 8072631 (inte allmän).

Utgångsdatum för Java

Utgångsdatum för 8u45 är den 14 juli 2015. Java går ut när en ny utgåva med korrigeringar av säkerhetsrisker blir tillgänglig. För system som inte kan nå Oracle-servrarna finns det en sekundär mekanism som upphör den här JRE:n (version 8u45) den 14 augusti 2015. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av Java om att uppdatera till den nyare versionen.

Buggfixar

Den här utgåvan innehåller korrigeringar av säkerhetsrisker. Mer information finns i Oracle Java SE Critical Patch Update Advisory.

För en lista över buggfixar som är inkluderade i den här utgåvan går du till sidan buggfixar i JDK 8u45.

» Versionskommentarer för 8u45

Java 8 Update 40 (8u40)

Viktiga funktioner i versionen

IANA-data 2014j
JDK 8u40 innehåller IANA-tidszonsdata version 2014j. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Buggfix: standardgränssnittsmetoder och statiska gränssnittsmetoder i JDI, JDWP och JDB. Sedan JDK 8 är det möjligt att ha direkt körbara statiska metoder och standardmetoder i gränssnitt. De här metoderna är inte körbara via JDWP eller JDI och kan därför inte felsökas korrekt. Mer information finns i kompatibilitetsguiden för JDK 8. Se 8042123.
Buggfix: Java Access Bridge kan nu aktiveras från kontrollpanelen för 32-bitars jre:er. Tidigare så togs kryssrutan Aktivera Java Access Bridge bort från kontrollpanelen för Java med en 64-bitars jre-avinstallation även när en 32-bitars JRE fortfarande fanns i systemet. Från och med utgåva JDK 8u40 behålls kryssrutan Aktivera Java Access Bridge, på Kontrollpanelen -> Hjälpmedel -> Hjälpmedelscenter -> Använd datorn utan bildskärm om det finns en 32-bitars jre. Det innebär att en användare kan aktivera Java Access Bridge via kontrollpanelen. Se 8030124.
Buggfix: JavaFX-mediestacken i OS X har moderniserats. En AVFoundation-baserad spelarplattform har lagts till i JavaFX-mediestacken. Den gamla QTKit-baserade plattformen kan nu tas bort för kompatibilitet med Mac App Store. Se 8043697 (inte allmän)
Buggfix: Saknade DOM-API:er. I utgåvan JDK 8u40 togs de gamla DOM-API:erna för insticksprogram bort av misstag. Om en applet kräver användning av com.sun.java.browser.dom.DOMService för att kommunicera med webbläsaren måste användaren uppdatera sin applet för att använda netscape.javascript.JSObject eller fortsätta använda JDK 8 Update 31. Det här problemet har lösts i bygge 26 och nya installationsprogram för 8u40 har publicerats. Om du får problem laddar du ned och kör de uppdaterade installationsprogrammen för JDK 8u40. Se 8074564.
Buggfix: OS X 10.10: Applikationer som körs med välkomstskärm har fokusproblem. Applikationer som startas via webstart eller som fristående applikationer som använder en välkomstskärm kan inte få tangentbordsfokus. Provisorisk lösning: Starta javaws med alternativet -Xnosplash. Det här problemet har lösts i bygge 27 och ett nytt installationsprogram för 8u40 har publicerats. Om du får problem laddar du ned och kör det uppdaterade installationsprogrammet för JDK 8u40. Se 8074668.
Förbättringar av verktyget Java Packager
Utgåva JDK 8u40 innehåller följande förbättringar av Java Packager:
- Kommandoradsargument kan överföras till självständiga applikationer. Standardargumenten definieras när paketet skapas. De kan åsidosättas av användaren när applikationen startas.
- Filassociationer kan ställas in när en självständig applikation installeras så att operativsystemet automatiskt kör applikationen för registrerade filtillägg eller MIME-typer.
- API:t UserJvmOptionsService är tillgängligt för att ändra JVM-alternativ i självständiga applikationer. De nya inställningarna används nästa gång applikationen startas.
- Flera ingångspunkter stöds för självständiga applikationer, vilket innebär att en svit av produkter kan paketeras i samma applikationspaket.
Inaktuella API:er
Mekanismerna endorsed-standards override och extension är inaktuella och kan tas bort i en framtida version. Det finns inga körningsändringar. Om du använder mekanismen "endorsed-standards override" eller "extension" i en befintlig applikation rekommenderar Oracle att du migrerar från att använda de mekanismerna. Som hjälp med att identifiera alla befintliga användningar av de mekanismerna är kommandoradsalternativet -XX:+CheckEndorsedAndExtDirs tillgängligt. Det utförs inte om något av följande villkor är sant:
- -Djava.endorsed.dirs eller systemegenskapen -Djava.ext.dirs har angetts för att ändra standardplats, eller
- katalogen ${java.home}/lib/endorsed finns, eller
- ${java.home}/lib/ext innehåller JAR-filer förutom de som JDK:t levererar, eller
- någon katalog för plattformsspecifika systemomfattande tillägg innehåller en JAR-fil.
Kommandoradsalternativet -XX:+CheckEndorsedAndExtDirs stöds i JDK 8u40 och senare utgåvor.
Skillnader på sidan för verktyget JJS
Den japanska versionen av hjälpsidan för jjs skiljer sig från den engelska versionen. Vissa av de alternativ som inte stöds har tagits bort från den engelska versionen av sidan för verktyget jjs. Den japanska versionen av dokumentet kommer att uppdateras i framtiden. Se 8062100 (inte allmän). För andra ändringar av sidan för verktyget jjs går du till sidan med verktygsförbättringar i JDK 8.
Ändringar i standardvärden för G1HeapWastePercent och G1MixedGCLiveThresholdPercent
Standardvärdet för G1HeapWastePercent har ändrats från 10 till 5 för att minska behovet av fullständiga GC:er. Av samma orsak har standardvärdet för G1MixedGCLiveThresholdPercent ändrats från 65 till 85.
Nytt gränssnitt för filtrering av åtkomst till Java-klasser
Med gränssnittet jdk.nashorn.api.scripting.ClassFilter kan du begränsa åtkomst till angivna Java-klasser från skript som körs av en Nashorn-skriptmotor. Mer information finns i Restricting Script Access to Specified Java Classes i användarhandboken för Nashorn och 8043717 (inte allmän).
Problem med tredjeparts JCE-leverantörer
Fixen för JDK-8023069 (i JDK 8u20) uppdaterade både leverantören SunJSSE och SunJCE, inklusive några interna gränssnitt. Några tredjeparts JCE-leverantörer (som RSA JSAFE) använder vissa sun.* internal-gränssnitt och fungerar därför inte med den uppdaterade SunJSSE-leverantören. De leverantörerna måste uppdateras för att fungera med den uppdaterade SunJSSE-leverantören. Om du påverkas av problemet kontaktar du JCE-leverantören för en uppdatering. Se 8058731.
Krypteringar har aktiverats igen i Solaris Crypto Framework
Om du använder Solaris 10 har en ändring gjorts för att aktivera åtgärder med MD5, SHA1 och SHA2 igen via Solaris Crypto Framework. Om du får ett CloneNotSupportedException-meddelande eller ett meddelande om PKCS11-felet CKR_SAVED_STATE_INVALID med JDK 8u40 måste du verifiera och använda programfixarna nedan, eller nyare versioner av dem:
- 150531-02 på sparc
- 150636-01 på x86
Uppdateringar av felsökningsguiden för NMT
NMT (Native Memory Tracking) är en Java HotSpot-VM-funktion som spårar intern minnesanvändning för en HotSpot-JVM. NMT kan användas för att övervaka interna VM-minnesallokeringar och för att diagnosticera VM-minnesläckor. Sidan med VM-förbättringar har uppdaterats med NMT-funktioner. Se sidan med Java Virtual Machine-förbättringar i Java SE 8. Felsökningsguiden har uppdaterats med NMT-funktioner. Se Native Memory Tracking.
Funktionen för flera JRE Launcher-instanser är inaktuell
Funktionen för att välja JRE-version vid start eller funktionen för flera JRE Launcher-instanser är inaktuell i JDK 8u40. Applikationer som kräver att specifika Java-versioner distribueras med den här funktionen måste växla till alternativa distribueringslösningar, som Java Web Start.
JavaFX-förbättringar
Från och med utgåva JDK 8u40 har JavaFX-kontrollerna utökats med stöd för hjälpmedelstekniker, vilket innebär att JavaFX-kontrollerna nu har hjälpmedelsfunktioner. Dessutom tillhandahålls ett allmänt API som utvecklare kan använda för att skriva egna kontroller med hjälpmedelsfunktioner. Hjälpmedelsstödet tillhandahålls på plattformarna Windows och Mac OS X och inkluderar:
- Stöd för att läsa JavaFX-kontroller av en skärmläsare
- JavaFX-kontroller kan navigeras med tangentbordet
- Stöd för ett specialläge med hög kontrast som gör kontroller mer synliga för användare.
Se 8043344 (inte allmän).

Utgåva JDK 8u40 innehåller nya användargränssnittskontroller för JavaFX: en talväljare, stöd för formaterad text och en standarduppsättning med aviseringsdialogrutor.
- Talväljare: en talväljare är ett enradigt textfält som användaren kan använda för att välja ett tal- eller objektvärde i en ordnad sekvens. Se klassen javafx.scene.control.Spinner för mer information.
- Formaterad text: det finns en ny klass, TextFormatter, med textformateringsfunktioner för underklasser till TextInputControl (som TextField och TextArea). Se klassen javafx.scene.control.TextFormatter för mer information.
- Dialogrutor: med klassen Dialog kan applikationer skapa egna anpassade dialogrutor. Dessutom finns klassen Alert, som utökar Dialog, som tillhandahåller stöd för ett antal förbyggda dialogrutetyper som enkelt kan visas för användare för att fråga efter ett svar. Se klasserna javafx.scene.control.Dialog javafx.scene.control.Alert javafx.scene.control.TextInputDialog javafx.scene.control.ChoiceDialog för mer information.
Se 8043350 (inte allmän).

Kommersiella funktioner

AppCDS (Application Class Data Sharing)
AppCDS (Application Class Data Sharing) utökar CDS vilket innebär att du kan placera klasser från standardkataloger för tillägg och på klassökvägen för applikationer i ett delat arkiv. Det här är en experimentell funktion som inte är licensierad för kommersiell användning. Se alternativet -XX:+UseAppCDS på sidan för verktyget Java Launcher.
Cooperative Memory Management
Från och med JDK 8u40 har begreppet "minnestryck" lagts till i JDK:t. Minnestryck är en egenskap som motsvarar den totala minnesanvändningen (RAM) i systemet. Ju högre minnestryck, desto närmare är det tills systemet får slut på minne. Det här är en experimentell funktion som inte är licensierad för kommersiell användning. Som en reaktion på det ökade minnestrycket försöker JDK:t minska sin minnesanvändning. Det görs i huvudsak genom att minska storleken på Java-högen. De åtgärder som JDK:t utför för att minska minnesanvändningen kan leda till försämrade prestanda. Det är ett avsiktligt val. Trycknivån tillhandahålls av applikationen via en JMX-MXBean med en skala från 0 (inget tryck) till 10 (nästan slut på minne). För att aktivera den här funktionen ska jdk.management.cmm.SystemResourcePressureMXBean registreras. Minnestrycket anges sedan med attributet "MemoryPressure".
Den nya kommandoradsflaggan -XX:MemoryRestriction med argumenten "none", "low", "medium" och "high" är också tillgänglig. Den här flaggan anger det ursprungliga trycket i JDK:t och fungerar även i vissa fall där MXBean inte är registrerad. Cooperative Memory Management kräver G1-GC:n (-XX:+UseG1GC). Den här funktionen är inte kompatibel med flaggan -XX:+ExplicitGCInvokesConcurrent.
Nya kommersiella flaggor
Två nya VM-alternativ är nu tillgängliga för kommersiella licensinnehavare:
- -XX:+ResourceManagement
- -XX:ResourceManagementSampleInterval=värde (millisekunder)
Mer information finns i dokumentationen för Java Launcher.
Ny dokumentation för MSI Installer
Microsoft Windows Installer (MSI) Enterprise JRE Installer Guide är tillgänglig. MSI Enterprise JRE Installer kräver en kommersiell licens för produktionsanvändning. Mer information om kommersiella funktioner och hur du aktiverar dem.

Utgångsdatum för Java

Utgångsdatum för 8u40 är den 14 april 2015. Java går ut när en ny utgåva med korrigeringar av säkerhetsrisker blir tillgänglig. För system som inte kan nå Oracles servrar avaktiverar en sekundär mekanism den här JRE-versionen (8u40) den 14 maj 2015. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av Java om att uppdatera till den nyare versionen.

Buggfixar

För en lista över buggfixar som är inkluderade i den här utgåvan går du till sidan med buggfixar i JDK 8u40.

» Versionskommentarer till 8u40

Java 8 Update 31 (8u31)

Viktiga funktioner i versionen

IANA Data 2014j
JJDK 8u31 innehåller IANA-tidszonsdata version 2014j. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
SSLv3 är avaktiverat som standard
Från och med JDK-utgåva 8u31 har protokollet SSLv3 (Secure Sockets Layer) avaktiverats och är normalt inte tillgängligt. Se egenskapen jdk.tls.disabledAlgorithms i filen \lib\security\java.security. Om du måste använda SSLv3 kan du återaktivera protokollet genom att ta bort "SSLv3" från egenskapen jdk.tls.disabledAlgorithms i filen java.security, alternativt så kan du ange den här säkerhetsegenskapen dynamiskt innan JSSE initieras.
Ändringar i kontrollpanelen för Java
Från och med JDK-utgåva 8u31 har protokollet SSLv3 tagits bort från alternativen på fliken Avancerat i kontrollpanelen för Java. Om du behöver SSLv3 för applikationer kan du återaktivera det manuellt på följande sätt:
- Aktivera protokollet SSLv3 på JRE-nivå: följ beskrivningen i föregående avsnitt.
- Aktivera protokollet SSLv3 på distribueringsnivå: redigera filen deployment.properties och lägg till följande:
  
  deployment.security.SSLv3=true

Utgångsdatum för Java

Utgångsdatum för 8u31 är den 14 april 2015. Java går ut när en ny utgåva med korrigeringar av säkerhetsrisker blir tillgänglig. För system som inte kan nå Oracles servrar avaktiverar en sekundär mekanism den här JRE-versionen (8u31) den 14 maj 2015. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av Java om att uppdatera till den nyare versionen.

Buggfixar

Den här utgåvan innehåller korrigeringar av säkerhetsrisker. Mer information finns i Oracle Java SE Critical Patch Update Advisory.

För en lista med buggfixar som är inkluderade i den här utgåvan går du till sidan buggfixar i JDK 8u31.

» Versionskommentarer till 8u31

Java 8 Update 25 (8u25)

Viktiga funktioner i versionen

IANA-data 2014c
JDK 8u25 innehåller IANA-tidszonsdata version 2014c. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
Buggfix: Minska inställningsläget för RC4 i listan med aktiverade chiffersystem
Den här fixen minskar inställningen för RC4-baserade chiffersystem i listan över aktiverade chiffersystem för leverantören SunJSSE. Se 8043200 (inte allmän).
Buggfix: JRE 8u20 kraschar vid användning av japanskt IM i Windows
VM:en kraschar vid användning av Swing-kontroller när vissa japanska eller kinesiska tecken skrivs i Windows. Problemet är nu åtgärdat. Se 8058858 (inte allmän).

Instruktioner för att avaktivera SSL version 3.0 i Oracle JDK och JRE

Oracle rekommenderar att användare och utvecklare avaktiverar version 3 av protokollet SSL.
» Hur kan Java-användare bekräfta att de inte är påverkade av säkerhetsrisken "Poodle" i SSL version 3.0?

Utgångsdatum för Java

Utgångsdatum för 8u25 är den 20 januari 2015. Java går ut när en ny utgåva med korrigeringar av säkerhetsrisker blir tillgänglig. För system som inte kan nå Oracle-servrarna finns det en sekundär mekanism som upphör den här JRE:n (version 8u25) den 20 februari 2015. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av Java om att uppdatera till den nyare versionen.

Buggfixar

Den här utgåvan innehåller korrigeringar av säkerhetsrisker. Mer information finns i Oracle Java SE Critical Patch Update Advisory.

För en lista med buggfixar som är inkluderade i den här utgåvan går du till sidan buggfixar i JDK 8u25.

» Versionskommentarer till 8u25

Java 8 Update 20 (8u20)

Viktiga funktioner i versionen

Nya flaggor har lagts till Java Management-API:t
Flaggorna MinHeapFreeRatio och MaxHeapFreeRatio har gjorts hanterbara. Det innebär att de kan ändras vid körningen med Management-API:t i Java. Stöd för flaggorna har även lagts till ParallelGC som del av policyn för anpassningsbar storlek.
Ändringar i Java Installer
- Ett nytt Microsoft Windows Installer-installationsprogram (MSI) för JRE:er för företag som användare kan använda för att installera JRE:n i hela företaget är tillgängligt. Mer information finns i avsnittet Ladda ned installationsprogrammet i JRE-installation för Microsoft Windows. MSI-installationsprogrammet för JRE:er för företag är endast tillgängligt som del av Java SE Advanced och Java SE Suite. Mer information om de här kommersiella produkterna finns i Java SE Advanced och Java SE Suite.
- Avinstallationsverktyget för Java är integrerat med installationsprogrammet som ett alternativ för att ta bort äldre versioner av Java från systemet. Ändringen gäller för 32- och 64-bitars Windows-plattform. Se Avinstallera JRE:n.
Ändringar i kontrollpanelen för Java
- Användare kan nu använda fliken Uppdatera i kontrollpanelen för Java för att automatiskt uppdatera 64-bitars JRE:er (förutom 32-bitars versioner) som är installerade på systemet.
- Säkerhetsnivån Medel har tagits bort. Endast nivåerna Hög och Mycket hög är nu tillgängliga. Appletar som inte följer de senaste säkerhetsmetoderna kan fortfarande ges behörighet att köra genom att inkludera de platser som är värd för dem i undantagsplatslistan. Med undantagslistan kan användare tillåta vissa appletar som skulle ha tillåtits genom att välja alternativet Medel men med olika inställningar för olika platser, vilket minskar risken med att använda mer tillåtande inställningar.
Java-kompileraren har uppdaterats
Kompileraren javac har uppdaterats för att implementera definit tilldelningsanalys för åtkomst till tomma final-fält med "this". Mer information finns i kompatibilitetsguiden för JDK 8.
Ändringar av Java-version som krävs för Java Plugin och Java Web Start
Den tidigaste version av Java som krävs för Java Plugin och Java Web Start är nu Java 5. Appletar som inte körs i Java 5 eller senare måste porteras till en senare version av Java för att fortsätta fungera. Appletar som har skrivits för tidigare versioner men som kan köras i Java 5 kommer att fortsätta fungera.
Ändringar i utdataformatering för UsageTracker Utdataformateringen för
UsageTracker har ändrats så att den använder citattecken, för att undvika förvirring i loggen. Det här kan kräva ändringar av läsningen av den typen av information. Funktionen kan konfigureras till samma format som i tidigare versioner, även om det nya formatet rekommenderas. Mer information finns i dokumentationen för Java-användningsspårning.
Ändringar i verktygen för Java-paketering
- Namnet på javafxpackager har ändrats till javapackager
- Alternativet "-B" har lagts till distribueringskommandot för javapackager för att ge dig möjlighet att skicka argument till de paketerare som används för att skapa kompletta applikationer. Mer information finns i dokumentationen för javapackager (Windows)/(Unix)
- Hjälpparameterargumentet har lagts till i Ant-uppgiftsreferensen för JavaFX. Det ger dig möjlighet att ange ett argument (i elementet ) för den paketerare som används för att skapa självständiga applikationer.

Utgångsdatum för Java

Utgångsdatum för 8u20 är den 14 oktober 2014. Java går ut när en ny utgåva med korrigeringar av säkerhetsrisker blir tillgänglig. För system som inte kan nå Oracles servrar upphör en sekundär mekanism den här JRE-versionen (version 8u20) den 14 november 2014. När något av villkoren uppfylls (den nya utgåvan blir tillgänglig eller utgångsdatumet nås) får användarna ytterligare varningar och påminnelser av Java om att uppdatera till den nyare versionen.

Buggfixar

För en lista med buggfixar som är inkluderade i den här utgåvan går du till sidan buggfixar i JDK 8u20.

» Versionskommentarer till 8u20

Java 8 Update 11 (8u11)

Den här utgåvan innehåller korrigeringar av säkerhetsrisker. Mer information finns i Oracle Critical Patch Update Advisory.

För en lista med buggfixar som är inkluderade i den här utgåvan går du till sidan buggfixar i JDK 8u11.

» Versionskommentarer till 8u11

Java 8 Update 5 (8u5)

Den här utgåvan innehåller korrigeringar av säkerhetsrisker. Mer information finns i Oracle Critical Patch Update Advisory.

För en lista med buggfixar som är inkluderade i den här utgåvan går du till sidan buggfixar i JDK 8u5.

» Versionskommentarer till 8u5

Java 8-utgåva

» Versionskommentarer till JDK och JRE 8