Java.com

Ladda ned Hjälp

Utskrivbar version

Viktiga ändringar i Java 8


Denna artikel gäller för:
  • Java-versioner: 8.0

På den här sidan beskrivs de ändringar i varje Java-version som påverkar slutanvändare. Mer information om ändringarna finns i versionskommentarerna till varje utgåva.
» Datum för Java-utgåvor


Java 8 Update 221 (8u221)

Viktiga funktioner i utgåvan
  • 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

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 8u221.

» Versionsinformation till 8u221


Java 8 Update 211 (8u211)

Viktiga funktioner i utgåvan
  • 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 uppdatering 201 (8u201)

Viktiga funktioner i utgåvan
  • 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

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 8u201.

» Versionskommentarer till 8u201


Java 8 Update 191 (8u191)

Viktiga funktioner i utgåvan
  • 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) vid körning på CPU-utgåvan från juli 2018 ( 8u181, 7u191 och 6u201 ) kan påträffa en avvikelse under upprättande av anslutning.
    De översta ramarna i applikationernas undantagsstackspårningar med 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 utgåvan
  • 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

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 8u181.

» Versionskommentarer till 8u181


Java 8 Update 171 (8u171)

Viktiga funktioner i utgåvan
  • 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
    En ny systemegenskap, 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 utlöses av ej utförda integritetskontroller under dekrypteringen. De här undantagen utlöses 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-chiffersystem 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

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 8u171.

» Versionskommentarer till 8u171


Java 8 Update 161 (8u161)

Viktiga funktioner i utgåvan
  • 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 nyckelstorleker (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

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 8u161.

» Versionskommentarer till 8u161


Java 8 Update 151 (8u151)

Viktiga funktioner i utgåvan
  • 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 för säkerhet 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

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 8u151.

» Versionskommentarer till 8u151


Java 8 Update 144 (8u144)

Viktiga funktioner i utgåvan
  • 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

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 8u144.

» Versionskommentarer till 8u144


Java 8 Update 141 (8u141)

Viktiga funktioner i utgåvan
  • 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 utlöser 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 enheter inkluderas inte som standard
    • Externa parameterenheter 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

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 8u141.

» Versionskommentarer till 8u141


Java 8 Update 131 (8u131)

Viktiga funktioner i utgåvan
  • 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 lager och fönstret från den aktiva fönsterkedjan ska ordnas över sina jämställda fönster.
    • Ändring av ordning ska inte utföras för ett fönster som är i ikonläget eller när övergången till ikonläget 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 utlöses 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. Egenskapen 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 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 regelbundna intervall 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 utgåvan
  • 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. 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 utlöses 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 utlöses 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 utlöses. 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
Kommentarer
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)".

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 utgåvan
  • 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 du 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 Roadmaphttp://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. Exempel:

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

    Därefter kör du 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:
  1. hotspot/jvm/os/processor/cpu_load
  2. 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

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

» Versionskommentarer till 8u111



Java 8 Update 101 (8u101)

Viktiga funktioner i utgåvan
  • 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 D-Trust-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 IdenTrust-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

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

    "Sonera Class1 CA" har tagits bort
    Rotcertifikatinstanscertifikatet "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 jarsigner
    Det nya alternativet -tsadigestalg har lagts till 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 2 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

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

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 utgåvan
  • 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 java-attribut 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.
Kommentarer

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

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 8u91.

» Versionskommentarer till 8u91


Java 8 Update 77 (8u77)

Viktiga funktioner i utgåvan
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.

Kommentarer

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 (Patch Set Updates) 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 utgåvan
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.

Kommentarer

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 utgåvan
  • 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 enhetsstorlek för XML
    En standardgräns för största enhetsstorlek 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 utgåvan

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 utgåvan
  • 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.
Kommentarer

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 utgåvan
  • 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:

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

    • Bifoga DumpJFR till en kärnfil:

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

    DumpJFR-verktyget dumpar JFR-data till en fil med namnet recording.jfr i den aktuella arbetsmappen. Se 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, 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 Java-konsolen, 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. Men:
      • När filen ruleset.xml tolkas kommer alla "customer"-block att visas (echo) på Java-konsolen 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:
<!ELEMENT ruleset (rule*)>
<!ATTRIBUTE ruleset href CDATA #IMPLIED>
<!ATTRIBUTE ruleset version CDATA #REQUIRED>

<!ELEMENT rule (id, action)>

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

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

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

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

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 utgåvan
  • IANA-data 2015d
    JDK 8u51 innehåller IANA-tidszonsdata version 2015d. Mer information finns i Versioner av tidszonsdata i JRE-programvaran.
  • Buggfix: La till 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: La till 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: La till Actalis till rotcertifieringsinstanser
    La till 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: La till ett nytt Entrust ECC-rotcertifikat
    La till 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 utgåvan
  • 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 utlösa 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 utgåvan
  • 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:
  • 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-minnestilldelningar 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 snurrkontroll, stöd för formaterad text och en standarduppsättning med aviseringsdialogrutor. 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 utgåvan
  • IANA-data 2014j
    JDK 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 utgåvan
  • 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 utgåvan
  • Nya flaggor har lagts till Java Management-API:t
    Flaggorna MinHeapFreeRatio och MaxHeapFreeRatio har gjorts hanteringsbara. 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


Du kanske även är intresserad av:




Välj språk | Om Java | Supportalternativ | Utvecklare
Sekretess  | Användningsvillkor | Varumärken | Friskrivning

Oracle