Wijzigingen in Java 8-release

Hoogtepunten Java 8-release

Dit artikel is van toepassing op:

Platform(s): Geen
Browser(s) Geen
Java-versie(s): 8.0

Op deze pagina worden de wijzigingen uitgelicht die van invloed zijn op eindgebruikers voor elke Java-release. Meer informatie over wijzigingen vindt u in de opmerkingen bij elke release.
» Java-releasedatums

Java 8 Update 441 (8u441)

Hoogtepunten van release

JDK 8u441 bevat IANA-tijdzonegegevens 2024b.
Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
JavaFX wordt niet langer opgenomen in JDK/JRE 8
Deze release, JDK en JRE 8 update 441, is de laatste release waarin JavaFX wordt gebundeld. Zoals aangekondigd in 2020 zal de ondersteuning voor JavaFX op JDK 8, de laatste commercieel ondersteunde versie van JavaFX van Oracle, eindigen in maart 2025. Daarom is JDK 8 update 441 de laatste upgrade van JDK/JRE 8 met JavaFX. Oracle blijft JavaFX alleen voor de nieuwste versies van Java ontwikkelen en uitbrengen als zelfstandige modules via het project OpenJFX. Zie voor meer informatie de Java SE lente 2024 trajectupdate.
Andere opmerkingen: Ondersteuning voor Tijdzone Database 2024b
IANA Tijdzone Database is bijgewerkt naar 2024b. Deze versie bevat voornamelijk wijzigingen om de historische gegevens voor Mexico, Mongolië en Portugal te verbeteren. Het verandert ook één tijdstempelafkorting, voor de tijdzone 'MET'. Ook Azië/Choibalsan is nu een alias voor Azië/Ulaanbaatar..
Zie voor meer informatie: JDK-8339637

De JDK up-to-date houden

Oracle raadt aan om de JDK bij te werken bij elke CPU. Als u wilt weten of een release de meest recente is, kunt u de pagina voor beveiligingsbasislijn gebruiken om te bepalen wat de laatste versie is voor elke releasefamilie.

CPU’s met oplossingen voor beveiligingsproblemen worden één jaar vooraf aangekondigd in 'Critical Patch Updates, Security Alerts and Bulletins'. Het wordt afgeraden deze JDK (versie 8u411) te gebruiken na de volgende kritieke patch-update, die gepland is voor 15 april 2025.

Met behulp van Java Management Service, die voor alle gebruikers beschikbaar is, kunnen kwetsbare Java-versies in uw systemen worden opgespoord. Abonnees van Java SE en klanten die Oracle Cloud gebruiken, kunnen gebruikmaken van Java Management Service om Java Runtime-versies bij te werken en nadere beveiligingscontroles uit te voeren, zoals het identificeren van mogelijk kwetsbare bibliotheken van derden die door uw Java-programma's worden gebruikt. Bestaande gebruiker van Java Management Service: klik hier om in te loggen bij uw dashboard. De documentatie van Java Management Service biedt een lijst met functies die voor iedereen beschikbaar zijn en met functies die alleen voor klanten beschikbaar zijn. Meer informatie over het gebruik van Java Management Service voor het controleren en beveiligen van uw Java-installaties.

Voor systemen die de Oracle Servers niet kunnen bereiken, verloopt deze JRE (versie 8u441) door een secundair mechanisme op 15 mei 2025. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren. Zie voor meer informatie 23.1.2 JRE Expiration Date in Java Platform, Standard Edition Deployment Guide.

Bugfixes

Deze release bevat ook fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Critical Patch Update Advisory. Zie Opmerkingen bij JDK-release 8u441 voor de volledige lijst met bugfixes in deze release.

Java 8 Update 431 (8u431)

Hoogtepunten van release

JDK 8u431 bevat IANA-tijdzonegegevens 2024a.
Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Belangrijke problemen opgelost: upgrade van JDK RPM laat invoer van zwevende alternatieven achter.
Probleem opgelost waarbij invoer in de 'java'- en 'javac'-groepen niet goed wordt beheerd tijdens een RPM upgrade.
Upgraden van een oudere Java RPM geïnstalleerd in een gedeelde directory (/usr/lib/jvm/jdk-${FEATURE}-oracle-${ARCH}) naar een Java RPM die is geïnstalleerd in een versiespecifieke directory (/usr/lib/jvm/jdk-${VERSION}-oracle-${ARCH}), heeft tot gevolg dat de oudere Java invoer in de 'java'- en 'javac'-groepen niet wordt verwijderd.
JDK-8336107 (niet openbaar)
Overige opmerkingen: nieuwe standaardlimieten in de JDK HTTP-implementaties
Er zijn nieuwe standaardlimieten toegevoegd aan HTTP in de JDK.
De ingebouwde JDK implementatie van de URL-protocolhandler voor HTTP (HttpURLConnection) heeft nu een standaardlimiet voor de maximale grootte van de responskopteksten die van een externe partij wordt geaccepteerd. De limiet is standaard ingesteld op 384 kB (393216 bytes) en wordt berekend als de cumulatieve grootte van alle koptekstnamen en koptekstwaarden plus een overhead van 32 bytes per koptekstnaam-waardepaar.
JDK-8328286 (niet openbaar)
Overige opmerkingen: In 2022 uitgegeven SSL.com TLS start-CA-certificaten toegevoegd
De volgende startcertificaten zijn toegevoegd aan de cacerts-truststore:
+ SSL.com
+ ssltlsrootecc2022
DN: CN=SSL.com TLS ECC startcertificaat 2022, O=SSL Corporation, C=US
+ SSL.com
+ ssltlsrootrsa2022
DN: CN=SSL.com TLS RSA startcertificaat 2022, O=SSL Corporation, C=US
Zie JDK-8341057.
Overige opmerkingen:TLS-servercertificaten wantrouwen die zijn verankerd door Entrust-startcertificaten en zijn uitgegeven na 11 november 2024
De JDK stopt met het vertrouwen van TLS-servercertificaten die worden uitgegeven na 11 november 2024 en die zijn verankerd door Entrust-startcertificaten, overeenkomstig soortgelijke plannen die onlangs zijn aangekondigd door Google en Mozilla. De lijst met betrokken certificaten bevat certificaten van het merk AffirmTrust, die worden beheerd door Entrust.
Zie JDK-8337664.

De JDK up-to-date houden

CPU’s met oplossingen voor beveiligingsproblemen worden één jaar vooraf aangekondigd in 'Critical Patch Updates, Security Alerts and Bulletins'. Het wordt afgeraden deze JDK (versie 8u431) te gebruiken na de volgende kritieke patch-update, die gepland is voor 21 januari 2025.

Voor systemen die de Oracle Servers niet kunnen bereiken, verloopt deze JRE (versie 8u431) door een secundair mechanisme op 21 februari 2025. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren. Zie voor meer informatie 23.1.2 JRE Expiration Date in Java Platform, Standard Edition Deployment Guide.

Bugfixes

Deze release bevat ook fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Critical Patch Update Advisory. Zie Opmerkingen bij JDK-release 8u431 voor de volledige lijst met bugfixes in deze release.

Java 8 Update 421 (8u421)

Hoogtepunten van release

JDK 8u421 bevat IANA-tijdzonegegevens 2024a.
Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Bekend probleem: gebruik van browsersleutelopslag in Windows
Zodra in Windows de functie 'Certificaten en sleutels in browsersleutelopslag gebruiken' is geactiveerd (wat standaard het geval is), hebben Java WebStart en Java Plugin toegang tot de certificaten die momenteel door de lokale machine worden vertrouwd. Er is geen garantie dat de volledige lijst met vertrouwde certificaten beschikbaar is, aangezien de certificaten dynamisch worden geladen. Als gevolg daarvan kunnen Java-applets en Java WebStart-applicaties problemen ondervinden met het valideren van handtekeningen en met beveiligde verbindingen, veroorzaakt door een gebrek aan relevante certificaten. Het implementatieframework heeft namelijk slechts toegang tot certificaten die 'actief' op het moment dat een applicatie wordt opgestart.
JDK-8330728 (niet openbaar).
Overige opmerkingen: argument STATIC=1 toevoegen aan het JRE-installatieprogramma
Met deze fix wordt argument STATIC=1 van het installatieprogramma toegevoegd en wordt argument RETAIN_ALL_VERSIONS=1 van het installatieprogramma afgekeurd. Met het doorgeven van STATIC=1 worden oudere JRE 8-versies tijdens een handmatige upgrade of een automatische update tegen verwijdering beschermd.
JDK-8313223 (niet openbaar).
Overige opmerkingen: GlobalSign R46- en E46-start-CA-certificaten toegevoegd
De volgende rootcertificaten zijn toegevoegd aan de cacerts truststore:
+ GlobalSign + globalsignr46 DN: CN=GlobalSign Root R46, O=GlobalSign nv-sa, C=BE + GlobalSign + globalsigne46 DN: CN=GlobalSign Root E46, O=GlobalSign nv-sa, C=BE
Zie JDK-8316138 voor meer informatie.
Overige opmerkingen: het installatieprogramma maakt een knooppuntdirectory op een nieuwe locatie
De JRE wordt geïnstalleerd op de volgende locatie: C:\Program Files\Java\latest\jre-$fullversion, waarin $fullversion de technische versie van de JRE is. Zo wordt bijvoorbeeld 8u421 geïnstalleerd in C:\Program Files\Java\latest\jre-1.8.0_421.

"C:\Program Files" wordt aangepast naar "C:\Program Files (x86)" voor 32-bits Java.

Er wordt een knooppunt gemaakt in C:\Program Files\Java\latest\jre-1.8. Deze verwijst naar de nieuwste JRE van de 8-familie.
JDK-8329700 (niet openbaar).

De JDK up-to-date houden

CPU’s met oplossingen voor beveiligingsproblemen worden één jaar vooraf aangekondigd in 'Critical Patch Updates, Security Alerts and Bulletins'. Het wordt afgeraden deze JDK (versie 8u421) te gebruiken na de volgende kritieke patch-update, die gepland is voor 15 oktober 2024.

Voor systemen die de Oracle Servers niet kunnen bereiken, verloopt deze JRE (versie 8u421) door een secundair mechanisme op 15 november 2024. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren. Zie voor meer informatie 23.1.2 JRE Expiration Date in Java Platform, Standard Edition Deployment Guide.

Bugfixes

Deze release bevat ook fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Critical Patch Update Advisory. Zie Opmerkingen bij JDK-release 8u421 voor de volledige lijst met bugfixes in deze release.

Java 8 Update 411 (8u411)

Hoogtepunten van release

JDK 8u411 bevat IANA-tijdzonegegevens 2024a.
Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Nieuwe functie: Certainly R1 en E1-rootcertificaten toegevoegd
De volgende rootcertificaten zijn toegevoegd aan de cacerts truststore:+ Certainly + certainlyrootr1 DN: CN=Certainly Root R1, O=Certainly, C=US + Certainly + certainlyroote1 DN: CN=Certainly Root E1, O=Certainly, C=US
Zie JDK-8321408
Nieuwe functie: Veilige validatiemodus voor XML-handtekeningen standaard activeren
De veilige validatiemodus voor XML-handtekeningen is standaard geactiveerd (eerder was dit niet standaard geactiveerd, tenzij deze met een beveiligingsmanager werd uitgevoerd). Als de validatie van XML-handtekeningen is geactiveerd, is dit afhankelijk van het strenger controleren van algoritmen en andere beperkingen zoals gespecificeerd door beveiligingseigenschap jdk.xml.dsig.secureValidationPolicy.
Zo nodig, en op eigen risico, kunnen applicaties de modus deactiveren door de eigenschap org.jcp.xml.dsig.secureValidation in te stellen op Boolean.FALSE met de API DOMValidateContext.setProperty().
Zie JDK-8259801

De JDK up-to-date houden

Voor systemen die de Oracle Servers niet kunnen bereiken, verloopt deze JRE (versie 8u411) door een secundair mechanisme op 16 augustus 2024. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren. Zie voor meer informatie 23.1.2 JRE Expiration Date in Java Platform, Standard Edition Deployment Guide.

Bugfixes

Deze release bevat ook fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Critical Patch Update Advisory. Zie Opmerkingen bij JDK-release 8u411 voor de volledige lijst met bugfixes in deze release.

Java 8 Update 401 (8u401)

Hoogtepunten van release

JDK 8u401 bevat IANA-tijdzonegegevens 2023c.
Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Nieuwe functie: nieuwe systeemeigenschap om de veilige validatiemodus voor XML-handtekeningen in of uit te schakelen.
Er is een nieuwe systeemeigenschap met de naam org.jcp.xml.dsig.secureValidation toegevoegd. Deze kan worden gebruikt voor het in- of uitschakelen van de veilige validatiemodus voor XML-handtekeningen. De systeemeigenschap moet voor inschakelen zijn ingesteld op "true" en voor uitschakelen op "false". Elke andere waarde voor de systeemeigenschap wordt behandeld als "false". Als de systeemeigenschap is ingesteld, heeft dit voorrang op de waarde voor de eigenschap XMLCryptoContext. De veilige validatiemodus is standaard ingeschakeld als u de code uitvoert met een SecurityManager, anders is deze standaard uitgeschakeld.
Zie JDK-8301260.
Nieuwe functie: JDK Flight Recorder-event voor deserialisatie
Er is een nieuw event voor JDK Flight Recorder (JFR) toegevoegd om deserialisatie van objecten te volgen. Wanneer JFR ingeschakeld is en de JFR-configuratie events voor deserialisatie bevat, zal JFR een event genereren wanneer het actieve programma een object probeert te deserialiseren. Het event voor deserialisatie wordt java/deserialization genoemd en is standaard uitgeschakeld. Het event voor deserialisatie bevat informatie die door het filtermechanisme voor de serialisatie gebruikt wordt. Als er een filter is ingeschakeld, geeft het JFR-event bovendien aan of het filter deserialisatie van het object geaccepteerd of geweigerd heeft.
Zie JDK-8261160.

De JDK up-to-date houden

CPU’s met oplossingen voor beveiligingsproblemen worden één jaar vooraf aangekondigd in 'Critical Patch Updates, Security Alerts and Bulletins'. Het wordt afgeraden deze JDK (versie 8u401) te gebruiken na de volgende kritieke patch-update, die gepland is voor 16 april 2024.

Klanten van Java SE Subscription-producten die JRE-updates/-installaties beheren voor een groot aantal desktops, wordt aangeraden Java Management Service (JMS) te gebruiken.

Voor systemen die de Oracle Servers niet kunnen bereiken, verloopt deze JRE (versie 8u401) door een secundair mechanisme op 16 mei 2024. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren. Zie voor meer informatie 23.1.2 JRE Expiration Date in Java Platform, Standard Edition Deployment Guide.

Bugfixes

Deze release bevat ook fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Critical Patch Update Advisory. Zie Opmerkingen bij JDK-release 8u401 voor de volledige lijst met bugfixes in deze release.

Java 8 Update 391 (8u391)

Hoogtepunten van release

JDK 8u391 contains IANA time zone data 2023c.
For more information, refer to Timezone Data Versions in the JRE Software.
Nieuwe functie: nieuwe JFR-event: jdk.SecurityProviderService
Er is een nieuw Java Flight Recorder (JFR)-event toegevoegd aan recorddetails van java.security.Provider.getService(String type, String algorithm) aanroepen.
Zie JDK-8254711
Verwijderde functie: RootCA1 Root Certificate van SECOM Trust System verwijderd
Het volgende root-certificaat van SECOM Trust System is verwijderd uit de cacerts-sleutelopslag:
+ alias name 'secomscrootca1 [jdk]' Onderscheiden naam: OU=Security Communication RootCA1, O=SECOM Trust.net, C=JP
Zie JDK-8295894
Verwijderde functie: verwijdering van ondersteuning Linux ARM32 voor JDK 8
Platformondersteuning voor Linux ARM32 in JDK 8 is verwijderd. Als gevolg hiervan zal de ARM32 Hard Float ABI download niet beschikbaar zijn. Besturingssystemen die ARM32 ondersteunden hebben het einde van hun levenscyclus bereikt, dus er is geen ondersteuning voor een besturingssysteem beschikbaar.
JDK-8305927 (niet openbaar).
Overig opmerkingen: start-CA-certificaat Certigna (Dhimyotis) is toegevoegd.
Het volgende startcertificaat is toegevoegd aan de vertrouwde opslag cacerts:
+ Certigna (Dhimyotis) + certignarootca DN: CN=Certigna , =0002 48146308100036, O=Dhimyotis, C=FR
Zie JDK-8314960.

De JDK up-to-date houden

CPU’s met oplossingen voor beveiligingsproblemen worden één jaar vooraf aangekondigd in 'Critical Patch Updates, Security Alerts and Bulletins'. Het wordt afgeraden deze JDK (versie 8u391) te gebruiken na de volgende kritieke patch-update, die gepland is voor 16 januari 2024.

Java SE Subscription-klanten die JRE-updates/installaties beheren voor een groot aantal desktops, wordt aangeraden om Java Advanced Management Console (AMC) te gebruiken.

Voor systemen die de Oracle Servers niet kunnen bereiken, verloopt deze JRE (versie 8u391) door een secundair mechanisme op 16 februari 2024. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren. Voor meer informatie zie vervaldatum 23.1.2 JRE in de Java Platform, Standard Edition Deployment Guide.

Bugfixes

Deze release bevat ook fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Critical Patch Update Advisory. Zie de pagina Opmerkingen bij JDK-release 8u391 voor de volledige lijst met bugfixes in deze release.

Java 8 update 381 (8u381)

Hoogtepunten van release

JDK 8u381 bevat IANA-tijdzonegegevens 2023c.
Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
NIeuwe functie: Aanvullende tekens toestaan voor ondersteuning van GB18030-2022
Het Chinese nationale normeringsinstituut (CESI) heeft onlangs GB18030-2022 gepubliceerd, een bijgewerkte versie van standaard GB18030 waarmee GB18030 in lijn komt met Unicode versie 11.0. De tekensetimplementatie voor deze nieuwe standaard heeft nu de eerdere standaard van 2000 vervangen. Een aantal wijzigingen in deze nieuwe standaard is echter incompatibel met de vorige implementatie. Voor wie de oude mappings moet gebruiken is er een nieuwe systeemeigenschap, jdk.charset.GB18030, geïntroduceerd Als u de waarde daarvan instelt op 2000 worden de mappings van de vorige JDK-releases voor de GB18030-tekenset gebruikt, die zijn gebaseerd op de standaard van 2000.
Zie JDK-8307229
JDK accepteert nu RSA-sleutels in PKCS#1-indeling
JDK-providers, zoals de RSA KeyFactory.impl van de SunRsaSign-provider kunnen nu privé en publieke RSA-sleutels in PKCS#1-format accepteren. Het privé of publieke RSA-sleutelobject moet de PKCS#1-indeling hebben en een codering die overeenkomt met de ASN.1-syntax voor een PKCS#1 privé en publieke RSA-sleutel.
Zie JDK-8023980
Overige opmerkingen: Ondersteuning voor cgroup v2 en verbeteringen aan 8u381
JDK 8u381 bevat verschillende verbeteringen en fixes om de ondersteuning van cgroup v1 en v2 voor containers te verbeteren. Tot de verbeteringen behoren het accuraat detecteren van de resourcelimieten van containers, het correct rapporteren van de verzamelde containermetrieken, het afdrukken van aanvullende containerinformatie en verbeterde stabiliteit van de applicatie in containeromgevingen.
Zie JDK-8307634
Overige opmerkingen: start-CA-certificaat TWCA is toegevoegd
Het volgende startcertificaat is toegevoegd aan de vertrouwde opslag cacerts:
+ TWCA + twcaglobalrootca DN: CN=TWCA Global Root CA, OU=Root CA, O=TAIWAN-CA, C=TW
Zie JDK-8305975
Overige opmerkingen: vier start-CA-certificaten GTS zijn toegevoegd
De volgende startcertificaten zijn toegevoegd aan de vertrouwde opslag cacerts:
+ Google Trust Services LLC + gtsrootcar1 DN: CN=GTS Root R1, O=Google Trust Services LLC, C=US + Google Trust Services LLC + gtsrootcar2 DN: CN=GTS Root R2, O=Google Trust Services LLC, C=US + Google Trust Services LLC + gtsrootecccar3 DN: CN=GTS Root R3, O=Google Trust Services LLC, C=US + Google Trust Services LLC + gtsrootecccar4 DN: CN=GTS Root R4, O=Google Trust Services LLC, C=US
Zie JDK-8307134
Overige opmerkingen: Twee start-CA-certificaten van Microsoft Corporation zijn toegevoegd
De volgende startcertificaten zijn toegevoegd aan de vertrouwde opslag cacerts:
+ Microsoft Corporation + microsoftecc2017 DN: CN=Microsoft ECC Root Certificate Authority 2017, O=Microsoft Corporation, C=US + Microsoft Corporation + microsoftrsa2017 DN: CN=Microsoft RSA Root Certificate Authority 2017, O=Microsoft Corporation, C=US
Zie JDK-8304760

De JDK up-to-date houden

CPU’s met oplossingen voor beveiligingsproblemen worden één jaar vooraf aangekondigd in 'Critical Patch Updates, Security Alerts and Bulletins'. Het wordt afgeraden deze JDK (versie 8u381) te gebruiken na de volgende kritieke patch-update, die gepland is voor 17 oktober 2023.

Java SE Subscription-klanten die JRE-updates/installaties beheren voor een groot aantal desktops, wordt aangeraden om Java Advanced Management Console (AMC) te gebruiken.

Voor systemen die de Oracle Servers niet kunnen bereiken, verloopt deze JRE (versie 8u381) door een secundair mechanisme op 17 november 2023. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren. Zie voor meer informatie 23.1.2 JRE Expiration Date in Java Platform, Standard Edition Deployment Guide.

Bugfixes

Deze release bevat ook fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Critical Patch Update Advisory. Zie de pagina Opmerkingen bij JDK-release 8u381 voor de volledige lijst met bugfixes in deze release.

Java 8 update 371 (8u371)

Hoogtepunten van release

JDK 8u371 bevat IANA-tijdzonegegevens 2022g.
Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Nieuwe functie: er is een standaard native GSS-API-bibliotheek toegevoegd in Windows
Er is een native GSS-API-bibliotheek toegevoegd aan JDK in het Windows-platform. De bibliotheek bevindt zich alleen aan de clientzijde en maakt gebruik van de standaardreferenties. Het wordt geladen als de systeemeigenschap sun.security.jgss.native is ingesteld op "waar". Een gebruiker kan nog steeds een native GSS-API-bibliotheek van derden laden door de systeemeigenschap sun.security.jgss.lib in te stellen met het pad.
Zie JDK-6722928
Verwijderde functies en opties: implementatie van de javax.script-engine en com.apple.concurrent.Dispatch zijn verwijderd voor macOS AArch64.
De AppleScript-engine die de API van de javax.script-engine implementeert, is verwijderd zonder vervanging. De AppleScript-engine heeft inconsistent gewerkt. Het bestand voor de configuratie van de services (META-INF/services) ontbrak en werkte alleen bij toeval bij het installeren van JDK 7 of JDK 8 op systemen waarop de versie van Apple van AppleScriptEngine.jar al op het systeem aanwezig was.
De API com.apple.concurrent.Dispatch was een API die alleen voor de Mac bestemd was. Het was overgenomen in JDK 7u4 met de overdracht van de code voor JDK 6 van Apple. Ontwikkelaars wordt aangeraden om in plaats hiervan de standaard-API's java.util.concurrent.Executor en java.util.concurrent.ExecutorService te gebruiken.
Zie JDK-8297475.
Overig opmerkingen: start-CA-certificaat Certigna (Dhimyotis) is toegevoegd.
Het volgende startcertificaat is toegevoegd aan de vertrouwde opslag cacerts:
+ Certigna (Dhimyotis) + certignarootca DN: CN=Certigna, O=Dhimyotis, C=FR
Zie JDK-8245654.
Overige opmerkingen: SSLv2Hello en SSLv3 zijn verwijderd uit de standaard geactiveerde TLS-protocols
SSLv2Hello en SSLv3 zijn verwijderd uit de standaard geactiveerde TLS-protocols

Als SSLv3 is verwijderd uit de beveiligingseigenschap jdk.tls.disabledAlgorithms, wordt na deze update door de API's SSLSocket.getEnabledProtocols(), SSLServerSocket.getEnabledProtocols(), SSLEngine.getEnabledProtocols() en SSLParameters.getProtocols() "TLSv1.3, TLSv1.2, TLSv1.1, TLSv1" geretourneerd. "SSLv3" wordt niet in deze lijst geretoureerd.
Als een client of server het SSLv3-protocol moet gebruiken, kunnen zij dit doen door het te activeren met de systeemeigenschappen jdk.tls.client.protocols of jdk.tls.server.protocols of met de API's SSLSocket.setEnabledProtocols(), SSLServerSocket.setEnabledProtocols() en SSLEngine.setEnabledProtocols().
Zie JDK-8190492.

De JDK up-to-date houden

Oracle raadt aan om de JDK bij te werken bij elke CPU. Gebruik de pagina Security Baseline pagina om de laatste versie te bepalen voor elke releasefamilie.

Kritieke patch-updates met oplossingen voor beveiligingsproblemen worden één jaar vooraf aangekondigd in Critical Patch Updates, Security Alerts and Bulletins. Het wordt afgeraden deze JDK (versie 8u371) te gebruiken na de volgende kritieke patch-update, die gepland is voor 18 juli 2023.

Java SE Subscription-klanten die JRE-updates/installaties beheren voor een groot aantal desktops, wordt aangeraden om Java Advanced Management Console (AMC) te gebruiken.

Voor systemen die de Oracle Servers niet kunnen bereiken, verloopt deze JRE (versie 8u761) door een secundair mechanisme op 18 augustus 2023. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren. Zie voor meer informatie 23.1.2 JRE Expiration Date in Java Platform, Standard Edition Deployment Guide.

Bugfixes

Deze release bevat ook fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Critical Patch Update Advisory. Zie de pagina Opmerkingen bij JDK-release 8u371 voor de volledige lijst met bugfixes in deze release.

Java 8 update 361 (8u361)

Hoogtepunten van release

JDK 8u361 bevat IANA-tijdzonegegevens 2022d, 2022e, 2022f.
Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Nieuwe functie: ondersteuning voor RSASSA-PSS in OCSP-respons
Een OCSP-respons die is ondertekend met het RSASSA-PSS-algoritme wordt nu ondersteund.
Zie JDK-8274471
Andere opmerkingen: FXML JavaScript-Engine standaard inactief
De “JavaScript-scriptengine” voor FXML is nu standaard inactief. Een .fxml-bestand met een PI (verwerkingsinstructie) "javascript" wordt niet langer standaard geladen en er wordt een uitzondering gegenereerd.
Dit kan worden geactiveerd door deze systeemeigenschap in te stellen: -Djavafx.allowjs=true
JDK-8294779 (niet openbaar)
Andere opmerkingen: onjuiste afhandeling van argumenten tussen aanhalingstekens in ProcessBuilder
ProcessBuilder wordt in Windows hersteld om een regressie op te lossen die wordt veroorzaakt door JDK-8250568. Eerder werd een argument voor ProcessBuilder dat begint met een dubbel aanhalingsteken en eindigt op een backslash gevolgd door een dubbel aanhalingsteken, onjuist aan een opdracht doorgegeven, dat tot gevolg kon hebben dat de opdracht mislukte. Het argument "C:\\Program Files\", werd door de opdracht gezien met extra dubbele aanhalingtekens. Hierdoor wordt het lang gebruikelijke gedrag hersteld waarmee de backslash voor het laatste dubbele aanhalingsteken niet op een speciale manier wordt behandeld.
See JDK-8282008
Andere opmerkingen: Standaard keepalive-time-out HttpURLConnection configureerbaar maken
Er zijn twee systeemeigenschappen toegevoegd waarmee het keepalive-gedrag van HttpURLConnection wordt beheerd als door de server geen keepalive-tijd wordt opgegeven. Er zijn twee eigenschappen gedefinieerd voor het apart beheren van verbindingen met servers and proxy's. Dit zijn respectievelijk http.keepAlive.time.server en http.keepAlive.time.proxy. U kunt meer informatie vinden in Networking Properties.
Zie JDK-8278067
Andere opmerkingen:VisualVM tool niet langer gebundeld
Deze versie van de JDK bevat niet langer een exemplaar van Java VisualVM. VisualVM is nu beschikbaar als aparte download via https://visualvm.github.io.
Zie JDK-8294184

De JDK up-to-date houden

CPU’s met oplossingen voor beveiligingsproblemen worden één jaar vooraf aangekondigd in 'Critical Patch Updates, Security Alerts and Bulletins'. Het wordt afgeraden deze JDK (versie 8u361) te gebruiken na de volgende kritieke patch-update, die gepland is voor 18 april 2023.

Java SE Subscription-klanten die JRE-updates/installaties beheren voor een groot aantal desktops, wordt aangeraden om Java Advanced Management Console (AMC) te gebruiken.

Voor systemen die de Oracle Servers niet kunnen bereiken, verloopt deze JRE (versie 8u361) door een secundair mechanisme op 18 mei 2023. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren. Zie voor meer informatie 23.1.2 JRE Expiration Date in Java Platform, Standard Edition Deployment Guide.

Bugfixes

Deze release bevat ook fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Critical Patch Update Advisory. Zie de pagina Opmerkingen bij JDK-release 8u361 voor de volledige lijst met bugfixes in deze release.

Java 8 update 351 (8u351)

Hoogtepunten van release

IANA TZ Data 2022b, 2022c.
Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Overige opmerkingen: upgrade van standaard PKCS12-MAC-algoritmen
De standaard-MAC-algoritmen die in een PKCS #12-sleutelopslag worden gebruikt, zijn bijgewerkt. Het nieuwe algoritme is gebaseerd op SHA-256 en is krachtiger dan het oude, dat gebaseerd is op SHA-1. Zie de beveiligingseigenschappen die beginnen met keystore.pkcs12 in het bestand java.security voor gedetailleerde informatie.
Zie JDK-8267880.
Overige opmerkingen: Inactieve JAR's die met SHA-1 zijn ondertekend
JAR's die zijn ondertekend met SHA-1-algoritmen zijn nu standaard beperkt en worden behandeld alsof deze niet zijn ondertekend. Dit is van toepassing op de algoritmen die worden gebruikt voor het overzicht, het ondertekenen en optioneel het tijdstempel van de JAR. Het is ook van toepassing op de algoritmen voor de ondertekening en het overzicht van de certificaten in de certificaatketen van de ondertekenaar van de code en de Timestamp Authority en de CRL's of OCSP-responsen die worden gebruikt om te verifiëren of deze certificaten zijn ingetrokken. Deze beperkingen zijn ook van toepassing op ondertekende JCE-providers.
Zie JDK-8269039.
Overige opmerkingen: 3DES en RC4 in Kerberos afkeuren
De coderingstypen (etypes) van Kerberos des3-hmac-sha1 en rc4-hmac zijn nu standaard afgekeurd en inactief. Gebruikers kunnen allow_weak_crypto = true instellen in het configuratiebestand krb5.conf om deze op eigen risico opnieuw te activeren (samen met andere zwakke etypen waaronder des-cbc-crc en des-cbc-md5). Als gebruikers een subset van de zwakke etypen willen deactiveren, kunnen zij voorkeursetypen expliciet opgeven in de instellingen default_tkt_enctypes, default_tgs_enctypes of permitted_enctypes.
Zie JDK-8139348.

De JDK up-to-date houden

CPU’s met oplossingen voor beveiligingsproblemen worden één jaar vooraf aangekondigd in 'Critical Patch Updates, Security Alerts and Bulletins'. Het wordt afgeraden deze JDK (versie 8u351) te gebruiken na de volgende kritieke patch-update, die gepland is voor 17 januari 2023.

Java SE Subscription-klanten die JRE-updates/installaties beheren voor een groot aantal desktops, wordt aangeraden om Java Advanced Management Console (AMC) te gebruiken.

Voor systemen die de Oracle Servers niet kunnen bereiken, verloopt deze JRE (versie 8u351) door een secundair mechanisme op 17 februari 2023. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren. Zie voor meer informatie 23.1.2 JRE Expiration Date in Java Platform, Standard Edition Deployment Guide.

Bugfixes

Deze release bevat ook fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Critical Patch Update Advisory. Zie de pagina JDK 8u351 Bug Fixes voor de volledige lijst met bugfixes in deze release.

» Opmerkingen bij release 8u351

Java 8 update 341 (8u341)

Hoogtepunten van release

IANA TZ Data 2022a.
Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Nieuwe functie: ondersteuning voor HTTPS-kanaalbinding voor Java GSS/Kerberos
Er is ondersteuning toegevoegd voor TLS-kanaalbindingstokens voor Negotiate/Kerberos-verificatie via HTTPS door middel van javax.net.HttpsURLConnection.

Voor een betere beveiliging worden steeds vaker kanaalbindingstokens vereist. Deze tokens geven de binding tussen de verbindingsbeveiliging (vertegenwoordigd door een TLS-servercertificaat) en verificatiereferenties op een hoger niveau (zoals een gebruikersnaam en wachtwoord) door van een client naar een server. De server kan detecteren of de client voor de gek is gehouden door een MITM en kan de sessie/verbinding uitschakelen.
Zie voor meer informatie: JDK-8279842.
Nieuwe functie: standaardactivering van TLSv1.3 in JDK 8u voor clientrollen
De TLSv1.3-implementatie is beschikbaar in JDK 8u vanuit 8u261 en is standaard actief voor serverrollen maar standaard inactief voor clientrollen. Vanaf deze release is TLSv1.3 nu ook standaard geactiveerd voor clientrollen. Ga voor meer details naar de sectie met aanvullende informatie van de Oracle JRE and JDK Cryptographic Roadmap.
Zie voor meer informatie: JDK-8245263.
Overige opmerkingen:update van java.net.InetAddress voor het detecteren van dubbelzinnige IPv4-adresconstanten
De klasse java.net.InetAddress is bijgewerkt voor strikte acceptatie van IPv4-adresconstanten met vier decimalen. De klassemethoden voor InetAddress zijn bijgewerkt en genereren nu een java.net.UnknownHostException voor ongeldige IPv4-adresconstanten. Als u deze controle wilt deactiveren, stelt u de nieuwe systeemeigenschap "jdk.net.allowAmbiguousIPAddressLiterals" in op "waar".
Zie voor meer informatie: JDK-8277608 (niet openbaar).
Overige opmerkingen:JDK-bundelextensies worden afgekapt tijdens het downloaden met Firefox 102.
Op oracle.com en java.com worden bepaalde JDK-bundelextensies afgekapt tijdens het downloaden bij gebruik van Firefox-versie 102. De gedownloade bundels hebben geen bestandsextensie, zoals ".exe", ".rpm", ".deb". Als u geen upgrade kunt uitvoeren naar Firefox ESR 102.0.1 of Firefox 103 wanneer deze release wordt vrijgegeven, kunt u de volgende tijdelijkse oplossing gebruiken:
‐Voeg na het downloaden handmatig een bestandsextensie toe aan de bestandsnaam.
‐Gebruik een andere browser.
Zie voor meer informatie: JDK-8277093.

De JDK up-to-date houden

CPU’s met oplossingen voor beveiligingsproblemen worden één jaar vooraf aangekondigd in 'Critical Patch Updates, Security Alerts and Bulletins'. Het wordt afgeraden deze JDK (versie 8u341) te gebruiken na de volgende kritieke patch-update, die gepland is voor 18 oktober 2022.

Java SE Subscription-klanten die JRE-updates/installaties beheren voor een groot aantal desktops, wordt aangeraden om Java Advanced Management Console (AMC) te gebruiken.

Voor systemen die de Oracle Servers niet kunnen bereiken, verloopt deze JRE (versie 8u341) door een secundair mechanisme op 18 november 2022. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren. Zie voor meer informatie 23.1.2 JRE Expiration Date in Java Platform, Standard Edition Deployment Guide.

Bugfixes

Deze release bevat ook fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Critical Patch Update Advisory. Zie de pagina JDK 8u341 Bug Fixes voor de volledige lijst met bugfixes in deze release.

» Opmerkingen bij release 8u341

Java 8 update 333 (8u333)

Hoogtepunten van release

IANA TZ Data 2021a.
Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Wijziging: alternatieve gegevensstreams in Windows automatisch inschakelen
De implementatie van java.io.File in Windows is gewijzigd, zodat standaard geen strikte validatiecontroles worden uitgevoerd op bestandspaden. Dit houdt onder meer in dat in het pad een dubbele punt (‘:’) is toegestaan op andere plaatsen dan meteen na de stationsletter. Ook zijn nu paden toegestaan die alternatieve gegevensstromen (Alternate Data Streams of ADS) in NTFS weergeven, zoals “bestandsnaam:stroomnaam”. Hiermee wordt het standaardgedrag van java.io.File hersteld naar wat het was vóór de kritieke patch-udate (CPU) van april 2022, waarbij in Windows niet standaard strikte validiteitscontroles werden uitgevoerd op bestandspaden. Als strikte padcontroles moeten worden ingeschakeld in java.io.File, moet de systeemeigenschap jdk.io.File.enableADS worden ingesteld op false (hoofdletterongevoelig). Dit kan bijvoorbeeld gewenst zijn als speciale apparaatpaden in Windows, zoals NUL: niet worden gebruikt.
Zie voor meer informatie: JDK-8285445.

De JDK up-to-date houden

CPU’s met oplossingen voor beveiligingsproblemen worden één jaar vooraf aangekondigd in 'Critical Patch Updates, Security Alerts and Bulletins'. Het wordt afgeraden deze JDK (versie 8u333) te gebruiken na de volgende CPU, die gepland is voor 19 juli 2022.

Java SE Subscription-klanten die JRE-updates/installaties beheren voor een groot aantal desktops, wordt aangeraden om Java Advanced Management Console (AMC) te gebruiken.

Voor systemen die de Oracle Servers niet kunnen bereiken, verloopt deze JRE (versie 8u333) via een secundair mechanisme op 19 augustus 2022. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren. Zie voor meer informatie 23.1.2 JRE Expiration Date in Java Platform, Standard Edition Deployment Guide.

Bugfixes

Deze release is gebaseerd op de vorige kritieke patch-update en bevat geen extra beveiligingsfixes. Zie de pagina Opmerkingen bij JDK-release 8u333 voor de volledige lijst met bugfixes in deze release.

» Opmerkingen bij release 8u333

Java 8 update 331 (8u331)

Hoogtepunten van release

IANA TZ Data 2021e.
Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Nieuwe functie: nieuwe XML-verwerkingslimieten
Er zijn drie verwerkingslimieten toegevoegd. Deze zijn:
- jdk.xml.xpathExprGrpLimit
  Beschrijving: hiermee wordt het aantal groepen dat een XPath-uitdrukking kan bevatten beperkt.
  Type: integer
  Waarde: een positief integer. De waarde kleiner dan of gelijk aan 0 betekent dat er geen limiet is. Als de waarde geen integer is, wordt NumberFormatException gegenereerd. Standaard 10.
- jdk.xml.xpathExprOpLimit
  Beschrijving: hiermee wordt het aantal operatoren dat een XPath-uitdrukking kan bevatten beperkt.
  Type: integer
  Waarde: een positief integer. De waarde kleiner dan of gelijk aan 0 betekent dat er geen limiet is. Als de waarde geen integer is, wordt NumberFormatException gegenereerd. Standaard 100.
- jdk.xml.xpathExprOpLimit
  Beschrijving: hiermee wordt het totale aantal XPath-operatoren in een XSL-opmaakprofiel beperkt.
  Type: integer
  Waarde: een positief integer. De waarde kleiner dan of gelijk aan 0 betekent dat er geen limiet is. Als de waarde geen integer is, wordt NumberFormatException gegenereerd. Standaard 10000.
Ondersteunde processoren
- jdk.xml.xpathExprGrpLimit en jdk.xml.xpathExprOpLimit worden ondersteund door de XPath-processor.
- Alle drie limieten worden ondersteund door de XSLT-processor.
Eigenschappen instelling
De eigenschappen voor de XSLT-processor kunnen worden gewijzigd met de TransformerFactory. Bijvoorbeeld:
```
<code>        TransformerFactory factory = TransformerFactory.newInstance();

        factory.setAttribute("jdk.xml.xpathTotalOpLimit", "1000");
```
Voor zowel de XPath- en XSLT-processoren kunnen de eigenschappen worden ingesteld met de systeemeigenschap en het configuratiebestand jaxp.properties dat zich bevindt in de directory conf van de Java-installatie. Bijvoorbeeld:
```
<code>        System.setProperty("jdk.xml.xpathExprGrpLimit", "20");
```
of in het bestand jaxp.properties,
```
<code>        jdk.xml.xpathExprGrpLimit=20
```
JDK-8270504 (niet openbaar)
Andere opmerkingen: alleen certificaten met juiste vertrouwensinstellingen weergeven als vertrouwde certificaatitems in macOS KeychainStore
In macOS worden alleen certificaten met de juiste vertrouwensinstellingen in de gebruikerskeychain weergegeven als vertrouwde certificaatitems in het sleutelopslagtype KeychainStore. Ook mislukt nu het aanroepen van de methode KeyStore::setCertificateEntry of de opdracht keytool -importcert voor een KeychainStore-sleutelopslag met een KeyStoreException. Roep in plaats hiervan de macOS-opdracht "security add-trusted-cert" aan om een vertrouwd certificaat toe te voegen aan de gebruikerskeychain.
JDK-8278449 (niet openbaar)
Andere opmerkingen: het ontleden van URL's in de ingebouwde JNDI-providers LDAP, DNS, RMI en CORBA is strikter gemaakt. De sterkte van de ontleding kan worden beheerd door systeemeigenschappen:
Het ontleden van URL's in de ingebouwde JNDI-providers LDAP, DNS, RMI en CORBA is strikter gemaakt. De sterkte van de ontleding kan worden beheerd door systeemeigenschappen:
```
<code>  -Dcom.sun.jndi.ldapURLParsing="legacy" | "compat" | "strict" (to control "ldap:" URLs)


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

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

  -Dcom.sun.jndi.corbaURLParsing="legacy" | "compat" | "strict" (to control "iiop:" and "iiopname:" URLs)
```
De standaardwaarde voor allemaal is "compat".
- Door de modus "legacy" wordt de nieuwe validering uitgeschakeld.
- Door de modus "compat" worden incompatibiliteiten beperkt.
- De modus "strict" is strikter en kan regressie veroorzaken door URL's af te wijzen die door een applicatie als ongeldig kunnen worden beschouwd.
Als een ongeldige URL wordt gevonden, treedt javax.naming.NamingException op (of een subklasse ervan).
JDK-8278972 (niet openbaar)

De JDK up-to-date houden

CPU’s met oplossingen voor beveiligingsproblemen worden één jaar vooraf aangekondigd in 'Critical Patch Updates, Security Alerts and Bulletins'. Het wordt afgeraden deze JDK (versie 8u331) te gebruiken na de volgende kritieke patch-update, die gepland is voor 19 juli 2022.

Java SE Subscription-klanten die JRE-updates/installaties beheren voor een groot aantal desktops, wordt aangeraden om Java Advanced Management Console (AMC) te gebruiken.

Voor systemen die de Oracle Servers niet kunnen bereiken, verloopt deze JRE (versie 8u331) door een secundair mechanisme op 19 augustus 2022. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren. Zie voor meer informatie 23.1.2 JRE Expiration Date in Java Platform, Standard Edition Deployment Guide.

Bugfixes

Deze release bevat ook fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Critical Patch Update Advisory. Zie de pagina JDK 8u331 Bug Fixes voor de volledige lijst met bugfixes in deze release.

» Opmerkingen bij release 8u331

Java 8 Update 321 (8u321)

Hoogtepunten van release

IANA TZ Data 2021b, 2021c, 2021d, 2021e.
JDK 8u321 bevat IANA-tijdzonegegevens 2021b, 2021c, 2021d, 2021e. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Nieuwe functie: nieuwe SunPKCS11-configuratie-eigenschappen
Met de SunPKCS11-provider worden nieuwe providerconfiguratie-attributen toegevoegd voor een beter beheer van het gebruik van native resources. De SunPKCS11-provider verbruikt native resources voor samenwerking met native PKCS11-bibliotheken. Om de native resources beter te kunnen beheren, worden aanvullende configuratie-attributen toegevoegd voor het beheer van de frequentie waarmee native referenties worden gewist en het onderliggende PKCS11-token wordt vernietigd na het uitloggen.
Zie voor meer informatie: JDK-8240256.
Verwijderde functies en opties: het GlobalSign-startcertificaat van Google is verwijderd.
Het volgende startcertificaat van Google is verwijderd uit de sleutelopslag cacerts:
+ alias name "globalsignr2ca [jdk]" Distinguished Name: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2
Zie voor meer informatie: JDK-8225083.
Overige opmerkingen: update van tijdzonegegevens naar 2021c
Bepaalde tijdzoneregels van de IANA-tijdzonedatabase, waarop de datum-/tijdbibliotheken van JDK zijn gebaseerd, zijn gewijzigd in 2021c. Opmerking: sinds deze update zijn bepaalde tijdzoneregels van vóór 1970 gewijzigd volgens de wijzigingen die zijn geïntroduceerd in 2021b. Raadpleeg de aankondiging van 2021b voor meer details.
Zie voor meer informatie: JDK-8274407.

De JDK up-to-date houden

Oracle raadt aan de JDK bij te werken bij elke Critical Patch Update (CPU). Als u wilt weten of een release de meest recente is, kunt u de beveiligingsbasispagina gebruiken om te bepalen wat de laatste versie is voor elke releasefamilie.

Kritieke patch-updates met oplossingen voor beveiligingsproblemen worden één jaar vooraf aangekondigd in Critical Patch Updates, Security Alerts and Bulletins. Het wordt afgeraden deze JDK (versie 8u291) te gebruiken na de volgende kritieke patch-update, die gepland is voor 20 juli 2021.

Java SE Subscription-klanten die JRE-updates/installaties beheren voor een groot aantal desktops, wordt aangeraden om Java Advanced Management Console (AMC) te gebruiken.

Voor systemen die de Oracle Servers niet kunnen bereiken, verloopt deze JRE (versie 8u2791) door een secundair mechanisme op 20 augustus 2021. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren. Zie voor meer informatie 23.1.2 JRE Expiration Date in Java Platform, Standard Edition Deployment Guide.

Bugfixes

Deze release bevat ook fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Critical Patch Update Advisory. Zie de pagina JDK 8u321 Bug Fixes voor de volledige lijst met bugfixes in deze release.

» Opmerkingen bij release 8u321

Java 8 update 311 (8u311)

Hoogtepunten van release

IANA TZ Data 2021a.
Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Nieuwe functie: Marlin Renderer in JDK 8u
Met ingang van versie 8u311 worden de Marlin Graphics Rasterizer en bijbehorende artefacten gebouwd en gedistribueerd als onderdeel van de JDK-/JRE-bundels. Het is niet de standaardweergave-engine. Er is echter een optie om deze te activeren door de volgende systeemeigenschap in te stellen:
sun.java2d.renderer=sun.java2d.marlin.MarlinRenderingEngine
Zie voor meer informatie: JDK-8143849.
Nieuwe functie: subset van contextspecifieke deserialisatiefilters
Sta toe dat applicaties contextspecifieke en dynamisch geselecteerde deserialisatiefilters kunnen configureren via een JVM-filterfactory die wordt aangeroepen om voor elke deserialisatiestroom een filter te selecteren. Het gedrag is een strikte subset van JEP 415: Context-Specific Deserialization Filters om toe te staan dat een filterfactory kan worden geconfigureerd met behulp van een eigenschap die is geconfigureerd op de opdrachtregel of in het bestand met beveiligingseigenschappen.
Raadpleeg Context-Specific Deserialization Filter en Serialization Filtering Guide voor meer informatie.
JDK-8268680 (niet openbaar)
Verwijderde functies en opties: het IdenTrust-startcertificaat is verwijderd.
Het volgende startcertificaat van IdenTrust is verwijderd uit de sleutelopslag 'cacerts':
+ alias name "identrustdstx3 [jdk]"
Distinguished Name: CN=DST Root CA X3, O=Digital Signature Trust Co.
Zie voor meer informatie: JDK-8225082.
Overige opmerkingen: Windows 11 wordt niet juist herkend door deze release.
Windows 11 wordt niet juist herkend door deze release. De eigenschap os.name is ingesteld op Windows 10 in Windows 11. In HotSpot-foutlogboeken wordt het besturingssysteem geïdentificeerd als Windows 10. Het HotSpot-foutlogboek bevat echter wel het buildnummer. Windows 11 bevat build 22000.194 of hoger.
Zie voor meer informatie: JDK-8274840.
Overige opmerkingen: de voorkeur voor standaard geactiveerde coderingssuites is bijgewerkt.
De standaardprioriteitsvolgorde van de coderingssuites voor TLS 1.0 naar TLS 1.3 is aangepast.
Voor TLS 1.3 heeft TLS_AES_256_GCM_SHA384 nu de voorkeur over TLS_AES_128_GCM_SHA256.
Voor TLS 1.0 naar TLS 1.2 is de prioriteit van enkele tussenliggende suites als volgt verlaagd:
- Coderingssuites waarmee Forward Secrecy niet wordt behouden, hebben een lagere prioriteit gekregen dan coderingssuites die wel ondersteuning bieden voor Forward Secrecy.
- Coderingssuites die SHA-1 gebruiken, hebben een lagere prioriteit gekregen.
Zie voor meer informatie: JDK-8163326.
Overige opmerkingen: het gedrag van HttpURLConnection als er geen geschikte proxy is gevonden, is gewijzigd.
Het gedrag van HttpURLConnection bij het gebruik van ProxySelector is gewijzigd in deze JDK-release. HttpURLConnection wordt gebruikt om terug te vallen op een directe verbindingspoging als het maken van verbinding door de geconfigureerde proxy('s) is mislukt. Met ingang van deze release is het standaardgedrag gewijzigd en wordt er niet langer een directe verbinding gebruikt als de eerste proxyverbindingspoging mislukt.
Zie voor meer informatie: JDK-8161016.

De JDK up-to-date houden

CPU’s met oplossingen voor beveiligingsproblemen worden één jaar vooraf aangekondigd in 'Critical Patch Updates, Security Alerts and Bulletins'. Het wordt afgeraden deze JDK (versie 8u311) te gebruiken na de volgende kritieke patch-update, die gepland is voor 18 januari 2022.

Java SE Subscription-klanten die JRE-updates/installaties beheren voor een groot aantal desktops, wordt aangeraden om Java Advanced Management Console (AMC) te gebruiken.

Voor systemen die de Oracle Servers niet kunnen bereiken, verloopt deze JRE (versie 8u311) door een secundair mechanisme op 18 februari 2022. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren. Zie voor meer informatie 23.1.2 JRE Expiration Date in Java Platform, Standard Edition Deployment Guide.

Bugfixes

Deze release bevat ook fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Critical Patch Update Advisory. Zie de pagina JDK 8u311 Bug Fixes voor de volledige lijst met bugfixes in deze release.

» Opmerkingen bij release 8u311

Java 8 update 301 (8u301)

Hoogtepunten van release

IANA TZ Data 2021a.
JDK 8u301 bevat IANA-tijdzonegegevens 2021a. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Nieuwe functie: genereren van PKCS12-sleutelopslag aanpassen
Nieuwe systeem- en beveiligingseigenschappen zijn toegevoegd om gebruikers in staat te stellen het genereren van PKCS #12-sleutelopslag aan te passen. Dit omvat algoritmen en parameters voor sleutelbeveiliging, certificaatbeveiliging en MacData. De gedetailleerde uitleg en mogelijke waarden voor deze eigenschappen vindt u in de sectie "PKCS12 KeyStore properties" van het bestand java.security.
Zie voor meer informatie: JDK-8076190.
Verwijderde functies en opties: startcertificaten met 1024-bits sleutels verwijderd
Startcertificaten met zwakke 1024-bits publieke RSA-sleutels zijn verwijderd uit de sleutelopslag 'cacerts'.
Zie voor meer informatie: JDK-8243559.
Verwijderde functies en opties: Sonera Class2 CA-certificaat van Telia Company verwijderd
Het volgende startcertificaat is verwijderd uit de truststore 'cacerts':
+ Telia Company + soneraclass2ca DN: CN=Sonera Class2 CA, O=Sonera, C=FI
Zie voor meer informatie: JDK-8225081.
Overige opmerkingen: upgrade van standaard PKCS12-coderingsalgoritmen
De standaardcoderingsalgoritmen die in een PKCS #12-sleutelopslag worden gebruikt, zijn bijgewerkt. De nieuwe algoritmen zijn gebaseerd op AES-256 en SHA-256, en zijn sterker dan de oude algoritmen die waren gebaseerd op RC2, DESede en SHA-1. Zie de beveiligingseigenschappen die beginnen met keystore.pkcs12 in het bestand java.security voor gedetailleerde informatie.
Voor compatibiliteit is een nieuwe systeemeigenschap met de naamkeystore.pkcs12.legacy gedefinieerd waarmee voor de algoritmen de oudere, zwakkere algoritmen worden gebruikt. Er is geen waarde gedefinieerd voor deze eigenschap.
Zie voor meer informatie: JDK-8153005.

De JDK up-to-date houden

Kritieke patch-updates met oplossingen voor beveiligingsproblemen worden één jaar vooraf aangekondigd in Critical Patch Updates, Security Alerts and Bulletins. Het wordt afgeraden deze JDK (versie 8u301) te gebruiken na de volgende kritieke patch-update, die gepland is voor 19 oktober 2021.

Voor Java SE Subscription klanten die JRE-updates/installaties beheren voor een groot aantal desktops is het aan te raden om Java Advanced Management Console (AMC) te gebruiken.

Voor systemen die de Oracle Servers niet kunnen bereiken, verloopt deze JRE (versie 8u301) door een secundair mechanisme op 19 november 2021. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren. Zie voor meer informatie 23.1.2 JRE Expiration Date in Java Platform, Standard Edition Deployment Guide.

Bugfixes

Deze release bevat ook fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Critical Patch Update Advisory. Zie de pagina JDK 8u301 Bug Fixes voor de volledige lijst met bugfixes in deze release.

» Opmerkingen bij release 8u301

Java 8 Update 291 (8u291)

Hoogtepunten van release

IANA TZ Data 2020e, 2020f, 2021a.
JDK 8u291 bevat IANA-tijdzonegegevens 2020e, 2020f, 2021a. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Overige opmerkingen: Nieuwe systeem- en beveiligingseigenschappen voor het beheren van de reconstructie van externe objecten door de ingebouwde JNDI RMI- en LDAP-implementaties van JDK
jdk.jndi.object.factoriesFilter: Met deze systeem- en beveiligingseigenschap kan een serieel filter worden opgegeven dat de set objectfactoryklassen bepaalt die objecten mogen instantiëren vanuit objectverwijzingen die worden geretourneerd door naamgevings-/directorysystemen. De factoryklasse die door de referentie-instance wordt genoemd, wordt gematcht met dit filter tijdens reconstructie van de externe verwijzing. De filtereigenschap ondersteunt op patronen gebaseerde filtersyntaxis met de indeling zoals aangegeven door JEP 290. Deze eigenschap is van toepassing op zowel de ingebouwde JNDI/RMI- als JNDI/LDAP-providerimplementaties. Volgens de standaardwaarde mag elke objectfactoryklasse die is opgegeven in de verwijzing, het object waarnaar wordt verwezen opnieuw maken.
JDK-8244473 (niet openbaar)
Overige opmerkingen: Standaard-java-versie wordt niet bijgewerkt voor jar-uitvoering bij dubbelklikken
Als de PATH-omgevingsvariabele een record bevat dat is geconfigureerd door Oracle JDK-installatieprogramma's uit nieuwere releases, voegt het Oracle JRE-installatieprogramma het pad in in de directory die de Java-opdrachten (java.exe, javaw.exe en javaws.exe) bevat in de PATH-omgevingsvariabele na dat record. Voorheen negeerde het Oracle JRE-installatieprogramma wijzigingen die door de PATH-omgevingsvariabele werden aangebracht door Oracle JDK-installatieprogramma's uit nieuwere releases en werd de waarde van de PATH-omgevingsvariabele onjuist bijgewerkt. Zie de volgende CSR voor aanvullende technische informatie: https://bugs.openjdk.java.net/browse/JDK-8259858
Zie JDK-8259215
Overige opmerkingen: TLS 1.0 en 1.1 uitschakelen
TLS 1.0 en 1.1 zijn versies van het TLS-protocol die niet meer als veilig worden beschouwd en zijn vervangen door veiligere en modernere versies (TLS 1.2 en 1.3).
Deze versies zijn nu standaard uitgeschakeld. In geval van problemen kunt u, op eigen risico, de versies opnieuw inschakelen door "TLSv1" en/of "TLSv1.1" te verwijderen uit de beveiligingseigenschap jdk.tls.disabledAlgorithms in het configuratiebestand java.security.
Zie voor meer informatie: JDK-8202343.
Overige opmerkingen: schakel TLS 1.0 en 1.1 uit voor Java Plugin-applets en Java Web Start-applicaties
TLS 1.0 en 1.1 zijn uitgeschakeld. Deze protocollen worden standaard NIET gebruikt door Java Plugin-applets en Java Web Start-applicaties. In geval van problemen kunt u de protocollen weer inschakelen via Java Control Panel.
JDK-8255892 (niet openbaar)

De JDK up-to-date houden

Kritieke patch-updates met oplossingen voor beveiligingsproblemen worden één jaar vooraf aangekondigd in Critical Patch Updates, Security Alerts and Bulletins. Het wordt afgeraden deze JDK (versie 8u291) te gebruiken na de volgende kritieke patch-update, die gepland is voor 20 juli 2021.

Java SE Subscription-klanten die JRE-updates/installaties beheren voor een groot aantal desktops, wordt aangeraden om Java Advanced Management Console (AMC) te gebruiken.

Bugfixes

Deze release bevat ook fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Critical Patch Update Advisory. Zie de pagina JDK 8u291 Bug Fixes voor de volledige lijst met bugfixes in deze release.

» Opmerkingen bij release 8u291

Java 8 Update 281 (8u281)

Hoogtepunten van release

IANA Data 2020d
JDK 8u281 bevat IANA tijdzonegegevens, versie 2020d. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Nieuwe functie: optie 'groupname' toegevoegd aan keytool-opdracht voor genereren van sleutelpaar
Er is een nieuwe optie -groupname toegevoegd aan keytool -genkeypair waarmee een gebruiker bij het genereren van een sleutelpaar een benoemde groep kan opgeven. Als u bijvoorbeeld keytool -genkeypair -keyalg EC -groupname secp384r1 gebruikt, wordt er een EC-sleutelpaar gegenereerd met gebruikmaking van de curve secp384r1. Omdat er mogelijk meerdere curves zijn van dezelfde grootte, kunt u beter de optie -groupname gebruiken dan de optie -keysize.
Zie voor meer informatie: JDK-8213400.
Nieuwe functie: Apache Santuario-bibliotheek bijgewerkt naar versie 2.1.4
De Apache Santuario-bibliotheek is bijgewerkt naar versie 2.1.4. Hiermee is een nieuwe systeemeigenschap geïntroduceerd, com.sun.org.apache.xml.internal.security.parser.pool-size.
Met deze nieuwe systeemeigenschap wordt de groepsgrootte ingesteld van de interne DocumentBuilder-cache die wordt gebruikt bij de verwerking van XML-handtekeningen. De functie is equivalent aan de systeemeigenschap org.apache.xml.security.parser.pool-size die in Apache Santuario wordt gebruikt en die dezelfde standaardwaarde (20) heeft.
Zie voor meer informatie: JDK-8231507.
Nieuwe functie: ondersteuning voor de extensie certificate_authorities
De extensie 'certificate_authorities' is een optionele extensie die in TLS 1.3 is geïntroduceerd. Deze wordt gebruikt voor het aangeven van de certificeringsinstanties (CA's) die door een eindpunt worden ondersteund. De extensie moet door het ontvangende eindpunt worden gebruikt voor aansturing van de certificaatkeuze.
Zie voor meer informatie: JDK-8206925.
Andere opmerkingen: Properties.loadFromXML gewijzigd in overeenstemming met specificatie
De implementatie van de methode java.util.Properties loadFromXML is gewijzigd, in overeenstemming met de specificatie van de methode. Dit houdt in dat nu bij de implementatie van de onderliggende XML-parser niet-compatibele XML documenten worden afgewezen door het genereren van een InvalidPropertiesFormatException-uitzondering, zoals voorgeschreven in de methode loadFromXML.
Zie voor meer informatie: JDK-8213325 .
Andere opmerkingen: zonenaam US/Pacific-New verwijderd als onderdeel van tzdata2020b
Na de JDK-update naar tzdata2020b zijn de al lang geleden verouderde bestanden pacificnew en systemv verwijderd. Als gevolg hiervan is de zonenaam 'US/Pacific-New' (VS/Pacific-Nieuw) die in het gegevensbestand pacificnew is gedeclareerd, niet meer beschikbaar voor gebruik.
Zie voor meer informatie: JDK-8254177.

De JDK up-to-date houden

Kritieke patch-updates met oplossingen voor beveiligingsproblemen worden één jaar vooraf aangekondigd in Critical Patch Updates, Security Alerts and Bulletins. Het wordt afgeraden deze JDK (versie 8u281) te gebruiken na de volgende kritieke patch-update, die gepland is voor 20 april 2021.

Java SE Subscription-klanten die JRE-updates/installaties beheren voor een groot aantal desktops, wordt aangeraden om Java Advanced Management Console (AMC) te gebruiken.

Voor systemen die de Oracle servers niet kunnen bereiken, verloopt deze JRE (versie 8u281) door een secundair mechanisme op 15 mei 2021. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren. Zie voor meer informatie 23.1.2 JRE Expiration Date in Java Platform, Standard Edition Deployment Guide.

Bugfixes

Deze release bevat ook fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Critical Patch Update Advisory. Zie de pagina JDK 8u281 Bug Fixes voor de volledige lijst met bugfixes in deze release.

» Opmerkingen bij release 8u281

Java 8 Update 271 (8u271)

Hoogtepunten van release

IANA Data 2020a
JDK 8u271 bevat IANA-tijdzonegegevens, versie 2020a. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Nieuwe functie: zwakke benoemde curves in TLS, CertPath en Signed JAR standaard gedeactiveerd
Zwakke benoemde curves worden standaard gedeactiveerd door ze toe te voegen aan de volgende beveiligingseigenschappen disabledAlgorithms: jdk.tls.disabledAlgorithms, jdk.certpath.disabledAlgorithms en jdk.jar.disabledAlgorithms. Met 47 zwakke benoemde curves die moeten worden gedeactiveerd, wordt het toevoegen van afzonderlijke benoemde curves aan elke eigenschap disabledAlgorithms een te grote belasting. Als oplossing hiervoor wordt een nieuwe beveiligingseigenschap, jdk.disabled.namedCurves, geïmplementeerd waarmee de benoemde curves kunnen worden weergegeven die gemeenschappelijk zijn voor alle eigenschappen disabledAlgorithms. Als u de nieuwe eigenschap in de eigenschappen disabledAlgorithms wilt gebruiken, laat u de volledige eigenschapnaam voorafgaan door het sleutelwoord include. Gebruikers kunnen nog steeds afzonderlijke benoemde curves toevoegen aan eigenschappen disabledAlgorithms, naast deze nieuwe eigenschap. Er kunnen geen andere eigenschappen worden opgenomen in de eigenschappen disabledAlgorithms.
Zie voor meer informatie: JDK-8233228.
Nieuwe functie: ondersteuning voor Kerberos-verwijzingen tussen realms (RFC 6806)
De Kerberos-client is uitgebreid met de ondersteuning van canonisatie van de principal name en verwijzingen tussen realms, zoals gedefinieerd door de RFC 6806-protocoluitbreiding.
Als gevolg van deze nieuwe functie kan de Kerberos-client profiteren van dynamischere omgevingsconfiguraties en is het niet noodzakelijk (vooraf) te weten hoe de realm van een doelprincipal (gebruiker of service) moet worden bereikt.
Zie voor meer informatie: JDK-8223172.
Verwijderde functie: de Java-plug-in is verwijderd uit JDK 8u voor Linux-, Solaris- en macOS-platforms
NPAPI wordt als een kwetsbare plug-in beschouwd en is in veel browsers gedeactiveerd. Er zijn momenteel geen browsers die de Java-plug-in, die is gebaseerd op NPAPI, ondersteunen op Linux-, Solaris- en macOS-platforms.
Vanaf 8u271 wordt het onderdeel van de Java-plug-in dat verantwoordelijk is voor integratie en interactie met een browser (vooral libnpjp2-bibliotheek) en een gekoppeld artefact niet gebouwd en maakt geen deel uit van de JRE-distributie op Linux-, Solaris- en macOS-platforms.
JDK-8240210 (niet openbaar)
Overige opmerkingen: eigenschap toegevoegd om LDAP-verificatiemechanismen te beheren waarmee mag worden geverifieerd via niet-versleutelde verbindingen
Een nieuwe omgevingseigenschap, jdk.jndi.ldap.mechsAllowedToSendCredentials, is toegevoegd om te beheren met welke LDAP-verificatiemechanismen referenties via niet-versleutelde LDAP-verbindingen mogen worden verzonden (een verbinding die niet is beveiligd met TLS). Een encrypted LDAP-verbinding is een verbinding die wordt geopend met behulp van een ldaps-schema, of een verbinding die wordt geopend met behulp van een ldap-schema en waarvoor vervolgens een upgrade wordt uitgevoerd naar TLS met een uitgebreide bewerking STARTTLS.
JDK-8237990 (niet openbaar)

De JDK up-to-date houden

Oracle raadt aan de JDK bij te werken bij elke Critical Patch Update (CPU). Om te bepalen of een release de laatste is, kan de volgende Security Baseline pagina worden gebruikt om te bepalen welke de laatste versie is voor elke releasefamilie.

Kritieke patch-updates met oplossingen voor beveiligingsproblemen worden één jaar vooraf aangekondigd in Critical Patch Updates, Security Alerts and Bulletins. Het wordt afgeraden deze JDK (versie 8u271) te gebruiken na de volgende kritieke patch-update, die gepland is voor 19 januari 2021.

Java SE Subscription-klanten die JRE-updates/installaties beheren voor een groot aantal desktops, wordt aangeraden om Java Advanced Management Console (AMC) te gebruiken.

Voor systemen die de Oracle Servers niet kunnen bereiken, verloopt deze JRE (versie 8u271) door een secundair mechanisme op 20 februari 2021. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren. Zie voor meer informatie 23.1.2 JRE Expiration Date in de Java Platform, Standard Edition Deployment Guide.

Bugfixes

Deze release bevat ook fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Critical Patch Update Advisory. Zie de pagina JDK 8u271 Bug Fixes voor de volledige lijst met bugfixes in deze release.

» Opmerkingen bij release 8u271

Java 8 Update 261 (8u261)

Hoogtepunten van release

IANA Data 2020a
JDK 8u261 bevat IANA-tijdzonegegevens, versie 2020a. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Nieuwe functie: wijzigingen afhankelijkheid JDK/JRE Runtime Windows Visual Studio Library (DLL)
Als onderdeel van doorlopend onderhoud wordt de Microsoft Visual Studio 2017-hulpprogrammaketen gebruikt om JDK 7 en JDK 8 voor Windows te maken. JDK 8u261, in de CPU van juli 2020, is gemaakt met Visual Studio 2017. Met de release van de CPU van oktober 2020 gaat JDK 7u281 over naar Visual Studio 2017.
JDK-8246783 (niet openbaar)
Nieuwe functie: JEP 332 Transport Layer Security (TLS) 1.3
JDK 8u261 bevat een implementatie van de Transport Layer Security (TLS) 1.3-specificatie (RFC 8446). Voor meer details, inclusief een lijst met de functies die worden ondersteund, raadpleegt u de documentatie in de Java Secure Socket Extension (JSSE) Reference Guide en JEP 332.
Zie voor meer informatie: JDK-814252.
Nieuwe functie: nieuwe systeemeigenschappen voor het configureren van de TLS-handtekeningschema's
Twee nieuwe systeemeigenschappen zijn toegevoegd om de TLS-handtekeningschema's in JDK aan te passen.
jdk.tls.client.SignatureSchemes is toegevoegd voor TLS aan clientzijde en jdk.tls.server.SignatureSchemes is toegevoegd voor de serverzijde.
Zie voor meer informatie: JDK-8242141.
Nieuwe functie: Onderhandelde efemere eindig-lichaam-Diffie-Hellman-parameters voor TLS
Met de JDK SunJSSE-implementatie worden nu de TLS FFDHE-mechanismen ondersteund die zijn gedefinieerd in RFC 7919. Als een server de TLS-extensie supported_groups of de benoemde groepen in de extensie niet kan verwerken, kunnen in applicaties de ondersteunde groepsnamen met jdk.tls.namedGroups worden aangepast of de FFDHE-mechanismen worden uitgeschakeld door de systeemeigenschap jsse.enableFFDHE in te stellen op 'niet waar'.
Zie voor meer informatie: JDK-8140436.

De JDK up-to-date houden

Kritieke patch-updates met oplossingen voor beveiligingsproblemen worden één jaar vooraf aangekondigd in Critical Patch Updates, Security Alerts and Bulletins. Het wordt afgeraden deze JDK (versie 8u261) te gebruiken na de volgende kritieke patch-update, die gepland is voor 13 oktober 2020.

Java SE Subscription-klanten die JRE-updates/installaties beheren voor een groot aantal desktops, wordt aangeraden om Java Advanced Management Console (AMC) te gebruiken.

Voor systemen die de Oracle servers niet kunnen bereiken, verloopt deze JRE (versie 8u261) door een secundair mechanisme op 13 november 2020. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren. Zie voor meer informatie 23.1.2 JRE Expiration Date in de Java Platform, Standard Edition Deployment Guide.

Bugfixes

Deze release bevat ook fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Critical Patch Update Advisory. Zie de pagina JDK 8u261 Bug Fixes voor een vollediger lijst met bugfixes in deze release.

» Opmerkingen bij release 8u261

Java 8 Update 251 (8u251)

Hoogtepunten van release

IANA Data 2019c
JDK 8u251 bevat IANA-tijdzonegegevens versie 2019c. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Nieuwe functie: ondersteuning toegevoegd voor PKCS#1 v2.2-algoritmen, waaronder RSASSA-PSS-handtekening
De SunRsaSign en SunJCE providers zijn uitgebreid met ondersteuning voor meer in PKCS#1 v2.2 gedefinieerde algoritmen, zoals RSASSA-PSS-handtekening en OAEP met behulp van FIPS 180-4-digest-algoritmen. Er zijn nieuwe constructors en methoden toegevoegd aan relevante JCA/JCE-klassen onder de pakketten java.security.spec en javax.crypto.spec ter ondersteuning van aanvullende RSASSA-PSS-parameters.
Zie voor meer informatie: JDK-8146293.
Overige opmerkingen: WebEngine beperkt het aanroepen van JavaScript-methoden voor bepaalde klassen.
JavaScript-programma's die worden uitgevoerd in de context van een met WebEngine geladen webpagina kunnen communiceren met Java-objecten die worden doorgegeven van de applicatie naar het JavaScript-programma. JavaScript-programma's die gebruikmaken van java.lang.Class-objecten zijn nu beperkt tot de volgende methoden:
getCanonicalName getEnumConstants getFields getMethods getName getPackageName getSimpleName getSuperclass getTypeName getTypeParameters isAssignableFrom isArray isEnum isInstance isInterface isLocalClass isMemberClass isPrimitive isSynthetic toGenericString toString

Er kunnen geen methoden worden aangeroepen op de volgende klassen:
java.lang.ClassLoader java.lang.Module java.lang.Runtime java.lang.System java.lang.invoke.* java.lang.module.* java.lang.reflect.* java.security.* sun.misc.*

JDK-8236798 (niet openbaar)
Overige opmerkingen: nieuwe Oracle specifieke systeemeigenschap voor JDK 8-updates valt terug op oudere Base64-coderingsindeling.
Oracle JDK 8u231 heeft de Apache Santuario-bibliotheken bijgewerkt naar v2.1.3. Deze upgrade heeft een probleem geïntroduceerd waarbij XML-ondertekening met behulp van Base64-codering heeft geresulteerd in het toevoegen van &#xd of &#13 aan de gecodeerde uitvoer. Deze gedragswijziging is in de Apache Santuario-codebase aangebracht om te voldoen aan RFC 2045. Het team van Santuario wil dat zijn bibliotheken blijven voldoen aan RFC 2045.
Zie voor meer informatie: JDK-8236645.

De JDK up-to-date houden

Kritieke patch-updates met oplossingen voor beveiligingsproblemen worden één jaar vooraf aangekondigd in Critical Patch Updates, Security Alerts and Bulletins. Het wordt afgeraden deze JDK (versie 8u251) te gebruiken na de volgende kritieke patch-update, die gepland is voor 14 juli 2020.

Voor systemen die de Oracle Servers niet kunnen bereiken, verloopt deze JRE (versie 8u251) door een secundair mechanisme op 14 augustus 2020. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren. Zie voor meer informatie 23.1.2 JRE Expiration Date in de Java Platform, Standard Edition Deployment Guide.

Bugfixes

Deze release bevat ook fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Critical Patch Update Advisory. Zie de pagina JDK 8u251 Bug Fixes voor een vollediger lijst met bugfixes in deze release.

» Opmerkingen bij release 8u251

Java 8 Update 241 (8u241)

Hoogtepunten van release

IANA Data 2019c
JDK 8u241 bevat IANA tijdzonegegevens, versie 2019c. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Nieuwe functie: toestaan dat SASL-mechanismen worden beperkt
Er is een beveiligingseigenschap toegevoegd, genaamd jdk.sasl.disabledMechanisms, die kan worden gebruikt om SASL-mechanismen te deactiveren. Een gedeaciveerd mechanisme wordt genegeerd als dit is opgegeven in het argument mechanisms van Sasl.createSaslClient of het argument mechanism van Sasl.createSaslServer. De standaardwaarde voor deze beveiligingseigenschap is leeg, wat betekent dat er standaard geen mechanismen zijn gedeactiveerd.
Zie voor meer informatie: JDK-8200400.
Nieuwe functie: upgrade van SunPKCS11-provider ondersteunt nu PKCS#11 v2.40.
De SunPKCS11-provider heeft een update gekregen met ondersteuning voor PKCS#11 v2.40. In deze versie is ondersteuning toegevoegd voor meer algoritmen, zoals het AES/GCM/NoPadding-cipher, DSA-handtekeningen waarbij de SHA-2-familie van berichtenoverzichten worden gebruikt en RSASSA-PSS handtekeningen als de overeenkomstige PKCS11-mechanismen door de onderliggende PKCS11-bibliotheek worden ondersteund.
Zie voor meer informatie: JDK-8080462.
Overige opmerkingen: nieuwe controles voor vertrouwd-ankercertificaten
Er zijn nieuwe controles toegevoegd om ervoor te zorgen dat vertrouwde ankers CA-certificaten zijn en de juiste extensies bevatten. Vertrouwde ankers worden gebruikt voor het valideren van certificaatketens die in TLS en ondertekende code worden gebruikt. In vertrouwd-ankercertificaten moet een basisbeperkingsextensie zijn opgenomen waarbij het cA-veld op 'true' is ingesteld. Bovendien moet, als er een sleutelgebruikextensie in het certificaat is opgenomen, het keyCertSign-bit zijn ingesteld.
JDK-8230318 (niet openbaar)
Overige opmerkingen: exacte overeenkomst vereist voor vertrouwd TLS-servercertificaat
Bij het opzetten van een TLS-verbinding wordt een TLS-servercertificaat alleen vertrouwd als het exact overeenkomt met een vertrouwd certificaat op de client.
JDK-8227758 (niet openbaar)
Overige opmerkingen: LuxTrust Global Root 2-certificaat toegevoegd
LuxTrust-startcertificaat is toegevoegd aan de cacerts-truststore.
Zie voor meer informatie: JDK-8232019.
Overige opmerkingen: vier Amazon-start-CA-certificaten toegevoegd
Amazon-startcertificaat is toegevoegd aan de cacerts truststore.
Zie voor meer informatie: JDK-8233223.
Bugfixes: ondersteuning voor OpenType CFF-lettertypen
Voorheen waren er in Oracle JDK 8 geen OpenType CFF-lettertypen (.otf-lettertypen) opgenomen in de standaard logische lettertypen (zoals 'Dialog' en 'SansSerif'). Dit had als gevolg dat er bij het weergeven van tekst symbolen ontbraken. In uitzonderlijke situaties, waarbij op het systeem alleen CFF-lettertypen waren geïnstalleerd, kon er een Java-uitzondering optreden.
Bij sommige Linux-distributies speelde dit probleem omdat daarin CFF-lettertypen nodig waren voor de ondersteuning van een aantal talen, met name CJK-talen (Chinees, Japans en Koreaans).
In Oracle JDK 8 worden nu deze CFF-lettertypen gebruikt, waardoor dit probleem is opgelost.
Zie voor meer informatie: JDK-8209672.
Bugfixes: betere afhandeling van seriële filters
De systeemeigenschap jdk.serialFilter kan alleen worden ingesteld via de opdrachtregel. Als het filter niet via de opdrachtregel is ingesteld, kan het worden ingesteld via java.io.ObjectInputFilter.Config.setSerialFilter. Het instellen van jdk.serialFilter via java.lang.System.setProperty werkt niet.
JDK-8231422 (niet openbaar)

Vervaldatum van Java

De vervaldatum voor 8u241 is 14 april 2020. Java verloopt wanneer een nieuwe release met oplossingen voor beveiligingsproblemen beschikbaar komt. Voor systemen die de Oracle Servers niet kunnen bereiken, vervalt deze JRE (versie 8u241) via een secundair mechanisme op 14 mei 2020. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren.

Bugfixes

Deze release bevat ook fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Critical Patch Update Advisory. Zie de pagina JDK 8u241 Bug Fixes voor een vollediger lijst met bugfixes in deze release.

» Opmerkingen bij release 8u241

Java 8 Update 231 (8u231)

Hoogtepunten van release

IANA Data 2019b
JDK 8u231 bevat IANA-tijdzonegegevens, versie 2019b. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Nieuwe functie: nieuwe systeemeigenschap jdk.jceks.iterationCount
Er is een nieuwe systeemeigenschap geïntroduceerd om het aantal herhalingen te beheren dat wordt gebruikt voor de jceks-sleutelopslag. De standaardwaarde blijft 200000, maar er kunnen waarden worden opgegeven tussen 10000 en 5000000. De naam van de nieuwe systeemeigenschap is jdk.jceks.iterationCount en de opgegeven waarde moet een geheel getal in het geaccepteerde bereik zijn. Als er een ontleedfout optreedt, wordt de standaardwaarde gebruikt.
JDK-8223269 (niet openbaar)
Nieuwe functie: nieuwe beveiligingevents voor Java Flight Recorder (JFR)
Er zijn vier nieuwe JFR-events toegevoegd aan het gebied van de beveiligingsbibliotheek. Deze events zijn standaard uitgeschakeld en kunnen worden ingeschakeld via de JFR-configuratiebestanden of via standaard-JFR-opties.
Zie voor meer informatie: JDK-8148188.
Verwijderde functies en opties: T2K Rasterizer en ICU Layout Engine verwijderd uit JavaFX
De T2K Rasterizer en ICU Layout Engine zijn verwijderd uit JavaFX.
Zie voor meer informatie: JDK-8187147.
Overige opmerkingen: [client-libs and javaFX] GTK3 is nu de standaard op Linux/Unix.
Nieuwere versies van Linux, Solaris en andere desktopomgevingen van het Unix-type maken gebruik van GTK3, maar blijven GTK2 ondersteunen.
Voorheen werden in JDK standaard de oudere GTK2-bibliotheken geladen. In deze release worden standaard de GTK3-bibliotheken geladen. Het laden wordt doorgaans getriggerd door het gebruik van de Swing GTK-stijl.
Het oude gedrag kan worden hersteld met de systeemeigenschap: -Djdk.gtk.version=2.2
Zie voor meer informatie: JDK-8222496.
Andere opmerkingen: Verouderde NIST EC-curves verwijderen uit de standaard-TLS-algoritmes
Met deze wijziging worden verouderde NIST EC-curves verwijderd uit de benoemde groepen die standaard worden gebruikt tijdens TLS-onderhandelingen. De verwijderde curves zijn sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1 en secp256k1.
Met de systeemeigenschap jdk.tls.namedGroups kunt u deze curves weer inschakelen. De eigenschap bevat een tussen aanhalingstekens geplaatste lijst van door komma's gescheiden, actieve benoemde groepen in volgorde van voorkeur. Bijvoorbeeld:
java -Djdk.tls.namedGroups="secp256r1, secp384r1, secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1" ...
JDK-8228825 (niet openbaar)

Vervaldatum van Java

De vervaldatum voor 8u231 is 14 januari 2020. Java verloopt wanneer een nieuwe release met oplossingen voor beveiligingsproblemen beschikbaar komt. Voor systemen die de Oracle Servers niet kunnen bereiken, verloopt deze JRE (versie 8u231) door een secundair mechanisme op 14 februari 2020. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren.

Bugfixes

Deze release bevat ook fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Critical Patch Update Advisory. Zie de pagina JDK 8u231 Bug Fixes voor de volledige lijst met bugfixes in deze release.

» Opmerkingen bij release 8u231

Java 8 Update 221 (8u221)

Hoogtepunten van release

IANA Data 2018i
JDK 8u221 bevat IANA-tijdzonegegevens, versie 2018i. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Nieuwe functie: Correcte detectie van Windows Server 2019 via de HotSpot-detectiefunctie voor het Windows-besturingssysteem
Vóór deze fix werd Windows Server 2019 herkend als "Windows Server 2016". Dit leidde tot onjuiste waarden in de systeemeigenschap os.name en het bestand hs_err_pid.
Zie voor meer informatie: JDK-8211106.
Verwijderde functies en opties: twee start-CA-certificaten van DocuSign verwijderd
Twee start-CA-certificaten van DocuSign zijn vervallen en verwijderd uit de sleutelopslag cacerts:
- aliasnaam "certplusclass2primaryca [jdk]"
  DN: CN=Class 2 Primary CA, O=Certplus, C=FR
- aliasnaam "certplusclass3pprimaryca [jdk]"
  DN: CN=Class 3P Primary CA, O=Certplus, C=FR
Zie voor meer informatie: JDK-8223499.
Verwijderde functies en opties: twee start-CA-certificaten van Comodo verwijderd
Twee start-CA-certificaten van Comodo zijn vervallen en verwijderd uit de sleutelopslag cacerts:
- aliasnaam "utnuserfirstclientauthemailca [jdk]"
  DN: CN=UTN-USERFirst-Client Authentication and Email, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
- aliasnaam "utnuserfirsthardwareca [jdk]"
  DN: CN=UTN-USERFirst-Hardware, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
Zie voor meer informatie: JDK-8222136.
Verwijderde functies en opties: start-CA 2-certificaat van T-Systems Deutsche Telekom verwijderd
Het start-CA 2-certificaat van T-Systems Deutsche Telekom is vervallen en verwijderd uit de sleutelopslag cacerts:
- aliasnaam "deutschetelekomrootca2 [jdk]"
  DN: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche Telekom AG, C=DE
Zie voor meer informatie: JDK-8222137.
Overige opmerkingen: tijdelijke oplossing voor installatie van Java Access Bridge
Als Java wordt geïnstalleerd op een Windows-systeem waarop een eerdere Java-versie is geïnstalleerd en een JAWS-instance wordt uitgevoerd, wordt de Java Access Bridge-functionaliteit mogelijk onderbroken. Na opnieuw opstarten is het mogelijk dat het bestand WindowsAccessBridge-64.dll ontbreekt in de systeemdirectory (C:\Windows\System32) voor 64-bits Java-producten, of de systeemdirectory die wordt gebruikt door WOW64 (C:\Windows\SysWoW64) voor 32-bits Java-producten.
Om onderbreking van de Java Access Bridge-functionaliteit te voorkomen, gebruikt u een van de volgende tijdelijke oplossingen:
- Stop JAWS voordat u het Java-installatieprogramma uitvoert.
- Verwijder de bestaande JRE-installatie(s) voordat u de nieuwe Java-versie installeert.
- Verwijder de bestaande JRE-installatie(s) nadat u de nieuwe Java-versie hebt geïnstalleerd en de computer opnieuw hebt opgestart.
Het doel van de tijdelijke oplossingen is om te voorkomen dat bestaande JRE-installatie(s) uit het Java-installatieprogramma worden verwijderd wanneer JAWS wordt uitgevoerd.
JDK-8223293 (niet openbaar)

Vervaldatum van Java

De vervaldatum voor 8u221 is 15 oktober 2019. Java verloopt wanneer een nieuwe release met oplossingen voor beveiligingsproblemen beschikbaar komt. Voor systemen die de Oracle servers niet kunnen bereiken, verloopt deze JRE (versie 8u221) door een secundair mechanisme op 15 november 2019. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren.

Bugfixes

Deze release bevat ook fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Critical Patch Update Advisory. Zie de pagina JDK 8u221 Bug Fixes voor de volledige lijst met bugfixes in deze release.

» Opmerkingen bij release 8u221

Java 8 Update 211 (8u211)

Hoogtepunten van release

IANA Data 2018g
JDK 8u211 bevat IANA tijdzonegegevens, versie 2018g. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Nieuwe functie: ondersteuning voor vierkante tekens voor de nieuwe Japanse jaartelling
Het codepunt, U+32FF, is door het Unicode Consortium gereserveerd voor de representatie van vierkante Japanse tekens voor de nieuwe jaartelling. Deze begint vanaf mei 2019. Met relevante methoden in de klasse Teken worden dezelfde eigenschappen geretourneerd als de bestaande tekens voor de Japanse jaartelling (bijv. U+337E voor 'Meizi'). Zie http://blog.unicode.org/2018/09/new-japanese-era.html voor meer informatie over het codepunt.
Zie voor meer informatie: JDK-8211398.
Wijziging: GlobalSign R6-startcertificaat toegevoegd
Het volgende startcertificaat is toegevoegd aan de truststore OpenJDK-cacerts:
- GlobalSign
  - globalsignrootcar6
    DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign-startcertificeringsinstantie - R6
JDK-8216577 (niet openbaar)
Wijziging: TLS-servercertificaten wantrouwen die zijn verankerd door Symantec Root
De JDK stopt met het vertrouwen van TLS-servercertificaten die worden uitgegeven door Symantec, overeenkomstig soortgelijke plannen die onlangs zijn aangekondigd door Google, Mozilla, Apple en Microsoft. De lijst met de betreffende certificaten omvat certificaten van het merk GeoTrust, Thawte en VeriSign, die door Symantec werden beheerd.
TLS-servercertificaten die zijn uitgegeven vóór of op 16 april 2019 worden vertrouwd tot ze verlopen. Certificaten die na die datum worden uitgegeven, worden afgewezen. Zie de DigiCert-ondersteuningspagina voor informatie over het vervangen van uw Symantec-certificaten door een DigiCert-certificaat (DigiCert heeft per 1 december 2017 de validatie en uitgifte overgenomen voor alle Website Security SSL/TLS-certificaten van Symantec).
Een uitzondering op dit beleid is dat TLS-servercertificaten die zijn uitgegeven via twee ondergeschikte certificaatautoriteiten die door Apple worden beheerd (en die hieronder worden geïdentificeerd), vertrouwd blijven voor zover ze vóór of op 31 december 2019 zijn uitgegeven.
Zie voor meer informatie: JDK-8207258.
Wijziging: naam voor nieuwe Japanse jaartelling
De naam van de plaatsaanduiding, 'NewEra', voor de Japanse jaartelling, die is begonnen vanaf 1 mei 2019, is vervangen door de door de Japanse overheid aangegeven naam 'Reiwa'. Applicaties die afhankelijk zijn van de naam van de plaatsaanduiding voor het verkrijgen van de singleton van de nieuwe jaartelling (JapaneseEra.valueOf("NewEra")) functioneren niet meer.
Zie voor meer informatie: JDK-8205432.
Wijziging: ondersteuning voor de nieuwe Japanse jaartelling in java.time.chrono.JapaneseEra
De klasse JapaneseEra en de bijbehorende methoden of(int) valueOf(String) en values() worden toegelicht om toekomstige aanvullingen aan te kunnen passen aan de Japanse jaartelling, bijvoorbeeld hoe de singleton-instances worden gedefinieerd, wat de gekoppelde hele waarden voor de jaartelling zijn, enzovoort.
Zie voor meer informatie: JDK-8212941.

Vervaldatum van Java

De vervaldatum voor 8u211 is 16 juli 2019. Java verloopt wanneer een nieuwe release met oplossingen voor beveiligingsproblemen beschikbaar komt. Voor systemen die geen verbinding kunnen maken met de Oracle-servers: voor deze JRE vervalt een secundair mechanisme op 16 augustus 2019. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren.

Bugfixes

Deze release bevat fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Java SE Critical Patch Update Advisory. Zie de pagina JDK 8u211 Bug Fixes voor een meer uitgebreide lijst met de bugfixes in deze release.

» Opmerkingen bij release 8u211

Java 8 Update 201 (8u201)

Hoogtepunten van release

IANA Data 2018e
JDK 8u201 bevat IANA-tijdzonegegevens, versie 2018e. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Wijziging: cipher-suites TLS anon en NULL zijn inactief.
De cipher-suites TLS anon (anoniem) en NULL zijn toegevoegd aan de beveiligingseigenschap jdk.tls.disabledAlgorithms en zijn nu standaard inactief.
Zie voor meer informatie: JDK-8211883.
Wijziging: met jarsigner wordt afgedrukt wanneer een tijdstempel komt te vervallen.
Met het hulpprogramma Jarsigner wordt nu meer informatie weergegeven over de levensduur van een JAR met tijdstempel. Er worden nieuwe waarschuwingen en foutmeldingen weergegeven wanneer een tijdstempel is vervallen of binnen één jaar vervalt.
Zie voor meer informatie: JDK-8191438.

Vervaldatum van Java

De vervaldatum voor 8u201 is 16 april 2019. Java verloopt wanneer een nieuwe release met oplossingen voor beveiligingsproblemen beschikbaar komt. Voor systemen die de Oracle Servers niet kunnen bereiken, vervalt deze JRE (versie 8u201) via een secundair mechanisme op 16 mei 2019. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren.

Bugfixes

Deze release bevat fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Java SE Critical Patch Update Advisory. Zie de pagina JDK 8u201 Bug Fixes voor een vollediger lijst met bugfixes in deze release.

» Opmerkingen bij release 8u201

Java 8 update 191 (8u191)

Hoogtepunten van release

IANA Data 2018e
JDK 8u191 bevat IANA tijdzonegegevens, versie 2018e. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Wijziging: gewijzigde locatie van het bestand usagetracker.properties in het centrale bestandssysteem
De bestandssysteemlocatie in Windows voor het bestand usagetracker.properties is gewijzigd van %ProgramData%\Oracle\Java\ in %ProgramFiles%\Java\conf
Er is geen wijziging in het bestandspad voor Linux, Solaris of macOS. JDK-8204901 (niet openbaar)
Wijziging: alle DES TLS-cipher-suites gedeactiveerd
DES TLS cipher-suites worden beschouwd als verouderd en moeten niet langer worden gebruikt. Op DES-gebaseerde cipher-suites zijn standaard gedeactiveerd in de SunJSSE-implementatie door de ID "DES" toe te voegen aan de beveiligingseigenschap jdk.tls.disabledAlgorithms. Deze cipher-suites kunnen opnieuw worden geactiveerd door "DES" te verwijderen uit de beveiligingseigenschap jdk.tls.disabledAlgorithms in het bestand java.security, of door de methode Security.setProperty() dynamisch aan te roepen. In beide gevallen moet het weer activeren van DES worden gevolgd door het toevoegen van DES-cipher-suites aan de lijst met geactiveerde cipher-suites met behulp van de methode SSLSocket.setEnabledCipherSuites() of SSLEngine.setEnabledCipherSuites().
Merk op dat voorafgaand aan deze wijziging, DES40_CBC-suites (maar niet alle DES-suites) zijn gedeactiveerd via de beveiligingseigenschap jdk.tls.disabledAlgorithms.
Zie voor meer informatie: JDK-8208350.
Wijziging: verwijdering van verschillende Symantec Root CA's
De volgende startcertificaten van Symantec zijn niet meer in gebruik en zijn verwijderd:
- 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
Zie voor meer informatie: JDK-8191031.
Wijziging: verwijdering van Baltimore Cybertrust Code Signing CA
Het volgende startcertificaat van Baltimore CyberTrust Code Signing is niet meer in gebruik en is verwijderd:
- baltimorecodesigningca
  DN: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE
Zie voor meer informatie: JDK-8189949.
Bugfix: LDAPS-communicatiefout
In applicatiecode die gebruikmaakt van LDAPS met een socketverbindingstime-out van <= 0 (de standaardwaarde) op de CPU van juli 2018 (8u181, 7u191 en 6u201), kan een uitzondering optreden bij het tot stand brengen van de verbinding.
De bovenste frames van de uitzonderingsstapeltracering van applicaties waarin dergelijke problemen optreden kunnen er als volgt uitzien:
javax.naming.ServiceUnavailableException: ; socket closed
at com.sun.jndi.ldap.Connection.readReply(Unknown Source)
at com.sun.jndi.ldap.LdapClient.ldapBind(Unknown Source) ...
Het probleem is opgelost en de fix is beschikbaar in de volgende releases:
- 8u181
- 7u191
Zie voor meer informatie: JDK-8211107.

Vervaldatum van Java

De vervaldatum voor 8u191 is 15 januari 2019. Java verloopt wanneer een nieuwe release met oplossingen voor beveiligingsproblemen beschikbaar komt. Voor systemen die de Oracle Servers niet kunnen bereiken, verloopt deze JRE (versie 8u191) door een secundair mechanisme op 15 februari 2019. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren.

Bugfixes

Deze release bevat fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Java SE Critical Patch Update Advisory. Zie de pagina JDK 8u191 Bug Fixes voor de volledige lijst met bugfixes in deze release.

» Opmerkingen bij release 8u191

Java 8 Update 181 (8u181)

Hoogtepunten van release

IANA Data 2018e
JDK 8u181 bevat IANA tijdzonegegevens, versie 2018e. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Verwijderde functie: verwijdering van Java DB
Java DB, ook wel bekend als Apache Derby, is verwijderd in deze release.
We raden u aan de nieuwste versie van Apache Derby rechtstreeks uit het Apache-project te downloaden via:
https://db.apache.org/derby
JDK-8197871 (niet openbaar)
Wijziging: verbeterde LDAP-ondersteuning
Eindpuntidentificatie is geactiveerd voor LDAPS-verbindingen.
Voor een stabielere werking van LDAPS-verbindingen (beveiligde LDAP via TLS) zijn algoritmen voor eindpuntidentificatie standaard geactiveerd.
Er zijn mogelijk situaties waarin sommige applicaties die eerder verbinding konden maken met een LDAPS-server dit niet meer kunnen. Voor dergelijke applicaties kan, als dit geschikt wordt geacht, eindpuntidentificatie worden gedeactiveerd met een nieuwe systeemeigenschap: com.sun.jndi.ldap.object.disableEndpointIdentification.
Definieer deze systeemeigenschap (of stel deze in op true) om algoritmen voor eindpuntidentificatie te deactiveren.
JDK-8200666 (niet openbaar)
Wijziging: beter doorlopen van stapels
Nieuwe toegangscontroles zijn toegevoegd tijdens de fase van deserialisatie voor het maken van objecten. Dit zou niet van invloed moeten zijn op normaal gebruik van deserialisatie. Het kan echter wel van invloed zijn op reflectieve frameworks waarvoor gebruik wordt gemaakt van interne API's van de JDK. De nieuwe controles kunnen indien nodig worden gedeactiveerd door de systeemeigenschap jdk.disableSerialConstructorChecks in te stellen op de waarde 'waar'. Dit kunt u doen door het argument -Djdk.disableSerialConstructorChecks=true toe te voegen aan de Java-opdrachtregel.
JDK-8197925 (niet openbaar)
Bugfix: JVM-crash tijdens G1 GC
Een klasse die als niet bereikbaar is beschouwd door de simultane markering van G1 kan worden opgezocht in ClassLoaderData/SystemDictionary en de bijbehorende velden _java_mirror of _class_loader kunnen in een hoofdmap of een ander bereikbaar object worden opgeslagen waardoor de klasse weer actief is. Wanneer een klasse op deze manier weer actief wordt gemaakt, moet het SATB-deel van G1 hier een melding over ontvangen, anders wordt die klasse in de simultane fase voor het opnieuw markeren van de markering ten onrechte ontladen.
Zie voor meer informatie: JDK-8187577.
Bugfix: betere stabiliteit met oudere NUMA-bibliotheken (-XX+UseNuma)
In een fix die is opgenomen in JDK 8 Update 152 wordt een regressie geïntroduceerd die mogelijk zorgt dat de HotSpot JVM crasht tijdens het opstarten wanneer de vlag 'UseNUMA' wordt gebruikt op Linux-systemen met versies van libnuma die ouder zijn dan 2.0.9. Dit probleem is opgelost.
Zie voor meer informatie: JDK-8198794.

Vervaldatum van Java

De vervaldatum voor 8u181 is 16 oktober 2018. Java verloopt wanneer een nieuwe release met oplossingen voor beveiligingsproblemen beschikbaar komt. Voor systemen die de Oracle servers niet kunnen bereiken, verloopt deze JRE (versie 8u181) door een secundair mechanisme op 16 november 2018. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren.

Bugfixes

Deze release bevat fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Java SE Critical Patch Update Advisory. Zie de pagina JDK 8u181 Bug Fixes voor de volledige lijst met bugfixes in deze release.

» Opmerkingen bij release 8u181

Java 8 Update 171 (8u171)

Hoogtepunten van release

IANA Data 2018c
JDK 8u171 bevat IANA tijdzonegegevens, versie 2018c. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Nieuwe functie: verbeterde sleutelopslagmechanismen
Een nieuwe beveiligingseigenschap met de naam jceks.key.serialFilter is geïntroduceerd. Als dit filter is geconfigureerd, wordt het door de JCEKS-sleutelopslag gebruikt bij de deserialisatie van het gecodeerde sleutelopslagobject dat is opgeslagen in een SecretKeyEntry. Als het niet is geconfigureerd of als het filterresultaat 'UNDECIDED' is (bijvoorbeeld als geen van de patronen overeenkomt), wordt het filter geraadpleegd dat is geconfigureerd door jdk.serialFilter.
Als de systeemeigenschap jceks.key.serialFilter ook is opgegeven, heeft dit voorrang op de hier gedefinieerde waarde voor beveiligingseigenschap.
Het filterpatroon gebruikt dezelfde indeling als jdk.serialFilter. Het standaardpatroon staat java.lang.Enum, java.security.KeyRep, java.security.KeyRep$Type en javax.crypto.spec.SecretKeySpec toe, maar wijst alle anderen af.
Klanten die een SecretKey opslaan die niet wordt geserialiseerd naar de types hierboven, moeten het filter zodanig aanpassen dat de sleutel extraheerbaar wordt.
JDK-8189997 (niet openbaar)
Nieuwe functie: systeemeigenschap voor het uitschakelen van het bijhouden van het laatste JRE-gebruik
Een nieuwe systeemeigenschap jdk.disableLastUsageTracking is geïntroduceerd om het bijhouden van het laatste JRE-gebruik uit te schakelen voor een actieve VM. Deze eigenschap kan op de opdrachtregel worden ingesteld met -Djdk.disableLastUsageTracking=true of -Djdk.disableLastUsageTracking. Als deze systeemeigenschap is ingesteld, wordt het bijhouden van het laatste JRE-gebruik uitgeschakeld, onafhankelijk van de eigenschapwaarde com.oracle.usagetracker.track.last.usage die is ingesteld in usagetracker.properties.
JDK-8192039 (niet openbaar)
Opmerking: gebruik CipherOutputStream
De specificatie van javax.crypto.CipherOutputStream is verhelderd en geeft nu aan dat deze klasse zoekt naar BadPaddingException en andere uitzonderingen die worden gegenereerd door negatief uitgevallen integriteitscontroles tijdens het decoderen. Deze uitzonderingen worden niet opnieuw gegenereerd, dus de client wordt niet op de hoogte gesteld dat integriteitscontroles negatief zijn uitgevallen. Hierdoor is deze klasse mogelijk niet geschikt voor gebruik met codering in een geverifieerde bewerkingsmodus (bijvoorbeeld GCM) als voor de applicatie een expliciete melding is vereist bij het mislukken van de verificatie. Deze applicaties kunnen de coderings-API rechtstreeks gebruiken als een alternatief voor het gebruik van deze klasse.
JDK-8182362 (niet openbaar)
Wijziging: aanvullend certificaat TeliaSonera-startcertificaat
"TeliaSonera Root CA v1" is toegevoegd aan de sleutelopslag cacerts.
JDK-8190851 (niet openbaar)
Wijziging: XML-handtekeningen gemaakt met EC-sleutels van minder dan 224 bits zijn uitgeschakeld.
Om de sterkte van SSL/TLS-verbindingen te verbeteren, zijn 3DES-coderingssuites uitgeschakeld in SSL/TLS-verbindingen in de JDK via de beveiligingseigenschap jdk.tls.disabledAlgorithms.
JDK-8175075 (niet openbaar)
Bugfix: RMI-verbindingen aan de serverzijde via HTTP-tunnel zijn uitgeschakeld.
RMI-verbindingen aan de serverzijde via HTTP-tunnel zijn standaard inactief in deze release. Dit gedrag kan worden teruggedraaid door de runtime-eigenschap sun.rmi.server.disableIncomingHttp de waarde false te geven. Opmerking: dit moet niet worden verward met de eigenschap sun.rmi.server.disableHttp waarmee HTTP-tunneling wordt uitgeschakeld aan de clientzijde en die standaard de waarde false heeft.
JDK-8193833 (niet openbaar)

Vervaldatum van Java

De vervaldatum voor 8u171 is 17 juli 2018. Java verloopt wanneer een nieuwe release met oplossingen voor beveiligingsproblemen beschikbaar komt. Voor systemen die de Oracle Servers niet kunnen bereiken, verloopt deze JRE (versie 8u171) door een secundair mechanisme op 17 augustus 2018. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren.

Bugfixes

Deze release bevat fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Java SE Critical Patch Update Advisory. Zie de pagina JDK 8u171 Bug Fixes voor een meer volledige lijst met bugfixes in deze release.

» Opmerkingen bij release 8u171

Java 8 Update 161 (8u161)

Hoogtepunten van release

IANA Data 2017c
JDK 8u161 bevat IANA tijdzonegegevens, versie 2017c. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Nieuwe functie: ondersteuning voor DHE-grootten tot maximaal 8192 bits en DSA-grootten tot maximaal 3072 bits
Breid de JDK-beveiligingsproviders uit om het genereren van 3072-bits DiffieHellman- en DSA-parameters, vooraf berekende DiffieHellman-parameters tot maximaal 8192 bits en vooraf berekende DSA-parameters tot maximaal 3072 bits te ondersteunen.
Zie voor meer informatie: JDK-8072452.
Nieuwe functie: Onderhandelde efemere eindig-lichaam-Diffie-Hellman-parameters voor TLS
Met de JDK SunJSSE-implementatie worden nu de TLS FFDHE-mechanismen ondersteund die zijn gedefinieerd in RFC 7919. Als een server de TLS-extensie supported_groups of de benoemde groepen in de extensie niet kan verwerken, kunnen in applicaties de ondersteunde groepsnamen met jdk.tls.namedGroups worden aangepast of de FFDHE-mechanismen worden uitgeschakeld door de systeemeigenschap jsse.enableFFDHEExtension in te stellen op false.
Zie voor meer informatie: JDK-8140436.
Nieuwe functie: aanvullende IDL-stubtypecontroles toevoegen aan methode org.omg.CORBA.ORBstring_to_object
In applicaties waarmee expliciet of impliciet org.omg.CORBA.ORB.string_to_object wordt aangeroepen en waarin de integriteit van het IDL-stubtype dat is betrokken bij de aanroepstroom ORB::string_to_object moet worden gegarandeerd, moet aanvullende IDL-stubtypecontrole worden opgegeven. Dit is een 'keuze'-functie en deze is niet standaard geactiveerd.
Voor het benutten van de aanvullende typecontrole wordt de lijst met geldige IDL-interfaceklassenamen van IDL-stubklassen geconfigureerd met een van de volgende acties:
- Het opgeven van de beveiligingseigenschap com.sun.CORBA.ORBIorTypeCheckRegistryFilter die zich bevindt in het bestand conf/security/java.security in Java SE 9 of in jre/lib/security/java.security in Java SE 8 en lager.
- Het opgeven van de systeemeigenschap com.sun.CORBA.ORBIorTypeCheckRegistryFilter met de lijst met klassen. Als de systeemeigenschap wordt ingesteld, overschrijft de waarde ervan de overeenkomende eigenschap die is gedefinieerd in de configuratie java.security.
Als de eigenschap com.sun.CORBA.ORBIorTypeCheckRegistryFilter niet is ingesteld, wordt de typecontrole alleen uitgevoerd voor een set klassenamen van de IDL-interfacetypen die overeenkomen met de ingebouwde IDL-stubklassen.
JDK-8160104 (niet openbaar)
Wijziging: validatie van publieke RSA-sleutel
In 8u161 wordt met de RSA-implementatie in de SunRsaSign-provider elke publieke RSA-sleutel afgewezen die een exponent heeft die niet binnen het geldige bereik valt zoals gedefinieerd in PKCS#1 versie 2.2. Deze wijziging is alleen van invloed op JSSE-verbindingen en op applicaties die in JCE zijn gebouwd.
JDK-8174756 (niet openbaar)
Wijziging: Diffie-Hellman-sleutels die kleiner zijn dan 1024 bits beperken
Diffie-Hellman-sleutels die kleiner zijn dan 1024 bits, worden als te zwak beschouwd om in de praktijk te gebruiken en moeten standaard worden beperkt in SSL/TLS/DTLS-verbindingen. Daarom zijn ook Diffie-Hellman-sleutels die kleiner zijn dan 1024 bits standaard gedeactiveerd door "DH keySize < 1024" toe te voegen aan de beveiligingseigenschap "jdk.tls.disabledAlgorithms" in het bestand java.security. Hoewel het niet wordt aanbevolen, kunnen beheerders de beveiligingseigenschap ("jdk.tls.disabledAlgorithms") bijwerken en kleinere sleutelgrootten toestaan (bijvoorbeeld door "DH keySize < 768" in te stellen).
JDK-8148108 (niet openbaar)
Wijziging: standaardsleutelgrootte van provider is bijgewerkt.
Met deze wijziging wordt voor de JDK-providers 2048 bits gebruikt als de standaardsleutelgrootte voor DSA in plaats van 1024 bits wanneer voor applicaties niet expliciet de objecten java.security.KeyPairGenerator en java.security.AlgorithmParameterGenerator met een sleutelgrootte zijn geïnitialiseerd.
Als er compatibiliteitsproblemen optreden, kan voor bestaande applicaties de systeemeigenschap jdk.security.defaultKeySize worden ingesteld die is geïntroduceerd in JDK-8181048 met het algoritme en de gewenste standaardsleutelgrootte.
JDK-8178466 (niet openbaar)

Vervaldatum van Java

De vervaldatum voor 8u161 is 17 april 2018. Java verloopt wanneer een nieuwe release met oplossingen voor beveiligingsproblemen beschikbaar komt. Voor systemen die de Oracle Servers niet kunnen bereiken, verloopt deze JRE (versie 8u161) door een secundair mechanisme op 17 mei 2018. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren.

Bugfixes

Deze release bevat fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Java SE Critical Patch Update Advisory. Zie de pagina JDK 8u161 Bug Fixes voor de volledige lijst met bugfixes in deze release.

» Opmerkingen bij release 8u161

Java 8 Update 151 (8u151)

Hoogtepunten van release

IANA Data 2017b
JDK 8u151 bevat IANA tijdzonegegevens, versie 2017b. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Certificaatwijzigingen: ingetrokken Swisscom-startcertificaat "swisscomrootevca2" verwijderd
Eén Swisscom-startcertificaat is ingetrokken door Swisscom en is verwijderd: 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 (niet openbaar)
Nieuwe functies Nieuwe beveiligingseigenschap om cryptopolicy te beheren
In deze release wordt een nieuwe functie geïntroduceerd waarbij de JCE-rechtsgebiedpolicybestanden die worden gebruikt voor de JDK kunnen worden beheerd via een nieuwe beveiligingseigenschap. In oudere releases moesten JCE-rechtsgebiedbestanden worden gedownload en afzonderlijk geïnstalleerd om toe te staan dat onbeperkte cryptografie werd gebruikt voor de JDK. De download- en installatiestappen zijn niet meer nodig. Voor het activeren van onbeperkte cryptografie kan de nieuwe beveiligingseigenschap crypto.policy worden gebruikt. Als de nieuwe beveiligingseigenschap (crypto.policy) is ingesteld in het bestand java.security of als de eigenschap dynamisch is ingesteld met de aanroep Security.setProperty() voordat het JCE-framework is geïnitialiseerd, wordt die instelling toegepast. De eigenschap is standaard ongedefinieerd. Als de eigenschap ongedefinieerd is en de verouderde JCE-rechtsgebiedbestanden niet bestaan in de verouderde directory lib/security, blijft de standaardwaarde voor cryptografisch niveau 'beperkt'. Als u de JDK zo wilt configureren dat onbeperkte cryptografie wordt gebruikt, stelt u crypto.policy in op de waarde 'onbeperkt'. Zie voor meer informatie de opmerkingen in het bestand java.security dat bij deze release wordt meegeleverd.
Opmerking: in Solaris wordt aanbevolen om de oude SVR4-pakketten te verwijderen voordat u de nieuwe JDK-updates installeert. Als een upgrade op basis van SVR4 (zonder de oude pakketten te verwijderen) wordt uitgevoerd op een eerdere JDK-release dan 6u131, 7u121, 8u111, moet u de nieuwe beveiligingseigenschap crypto.policy in het bestand java.security instellen.

Omdat de oude JCE-rechtsgebiedbestanden in <java-home>/lib/security blijven staan, voldoen ze mogelijk niet aan de nieuwste beveiligingsnormen voor JAR-ondertekening, die zijn vernieuwd in 6u131, 7u121, 8u111 en latere updates. Een uitzondering zoals de volgende wordt mogelijk weergegeven als de oude bestanden worden gebruikt:

Veroorzaakt door: java.lang.SecurityException: rechtsgebiedpolicybestanden zijn niet ondertekend door vertrouwde ondertekenaars. op javax.crypto.JceSecurity.loadPolicies(JceSecurity.java:593) op javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:524)
Zie voor meer informatie: JDK-8157561.
Wijzigingen refactoratie van bestaande providers zodat de verwijzen naar dezelfde constanten voor standaardwaarden voor de sleutellengte
Voor dit probleem zijn twee belangrijke wijzigingen aangebracht:
1. Er is een nieuwe systeemeigenschap geïntroduceerd waarmee gebruikers de standaardsleutelgrootte kunnen configureren die voor de JDK-providerimplementaties van KeyPairGenerator en AlgorithmParameterGenerator wordt gebruikt. Deze eigenschap heet "jdk.security.defaultKeySize" en de waarde van deze eigenschap is een lijst met door komma's gescheiden items. Elk item bestaat uit een niet-hoofdlettergevoelige algoritmenaam en de bijbehorende standaardsleutelgrootte (in decimalen) gescheiden door ':'. Bovendien worden spaties genegeerd.
De eigenschap heeft standaard geen waarde en JDK-providers gebruiken hun eigen standaardwaarden. Items die een onbekende algoritmenaam bevatten, worden genegeerd. Als de opgegeven standaardsleutelgrootte geen parseerbaar decimaal geheel getal is, wordt dat item ook genegeerd.
1. Met de DSA KeyPairGenerator-implementatie van de SUN-provider wordt java.security.interfaces.DSAKeyPairGenerator niet meer geïmplementeerd. Met toepassingen waarmee het object DSA KeyPairGenerator van de SUN-provider object wordt omgezet in een java.security.interfaces.DSAKeyPairGenerator kan de systeemeigenschap "jdk.security.legacyDSAKeyPairGenerator" worden ingesteld. Als de waarde van deze eigenschap 'waar' is, wordt met de SUN-provider een object DSA KeyPairGenerator geretourneerd waarmee de interface java.security.interfaces.DSAKeyPairGenerator wordt geïmplementeerd. Met deze verouderde implementatie wordt dezelfde standaardwaarde gebruikt als die is opgegeven met javadoc in de interface.
Deze eigenschap heeft standaard geen waarde en met de SUN-provider wordt een object DSA KeyPairGenerator geretourneerd waarmee de eerder genoemde interface niet wordt geïmplementeerd. Hierdoor kan de eigen providerspecifieke standaardwaarde worden bepaald zoals vermeld in de klasse java.security.KeyPairGenerator of met de systeemeigenschap 'jdk.security.defaultKeySize', indien ingesteld.
JDK-8181048 (niet openbaar)

Vervaldatum van Java

De vervaldatum voor 8u151 is 16 januari 2018. Java verloopt wanneer een nieuwe release met oplossingen voor beveiligingsproblemen beschikbaar komt. Voor systemen die de Oracle Servers niet kunnen bereiken, verloopt deze JRE (versie 8u151) door een secundair mechanisme op 16 februari 2018. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren.

Bugfixes

Deze release bevat fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Java SE Critical Patch Update Advisory. Zie de pagina JDK 8u151 Bug Fixes voor de volledige lijst met bugfixes in deze release.

» Opmerkingen bij release 8u151

Java 8 Update 144 (8u144)

Hoogtepunten van release

IANA Data 2017b
JDK 8u144 bevat IANA tijdzonegegevens, versie 2017b. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Bugfix: met java.util.zip.ZipFile.getEntry() wordt voor directory-invoer nu altijd de ZipEntry-instance geretourneerd met een invoernaam die eindigt op /
java.util.zip.ZipEntry In het API-document staat dat de naam van directory-invoer altijd eindigt met een /. In eerdere JDK-releases wordt met java.util.zip.ZipFile.getEntry(String entryName) mogelijk een ZipEntry-instance geretourneerd met een invoernaam die niet eindigt met een / voor een bestaande ZIP-directory-invoer wanneer het doorgegeven argument entryName niet eindigt met een / en er in het ZIP-bestand een overeenkomstige ZIP-directory-invoer staat met de naam entryName + /. In deze release eindigt de naam van de ZipEntry-instance die wordt geretourneerd door java.util.zip.ZipFile.getEntry() altijd op / voor elke ZIP-directory-invoer.
Als u de oude situatie wilt herstellen, moet de systeemeigenschap jdk.util.zip.ensureTrailingSlash worden ingesteld op 'niet waar'.

Met deze wijziging wordt een regressie bij het verifiëren van ondertekende JAR's opgelost die is geïntroduceerd in JDK 8u141. Door deze regressie konden bepaalde WebStart-applicaties niet worden geladen.
Zie voor meer informatie: JDK-8184993.

Vervaldatum van Java

De vervaldatum voor 8u144 is 17 oktober 2017. Java verloopt wanneer een nieuwe release met oplossingen voor beveiligingsproblemen beschikbaar komt. Voor systemen die de Oracle servers niet kunnen bereiken, verloopt deze JRE (versie 8u144) door een secundair mechanisme op 17 november 2017. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren.

Bugfixes

Deze release bevat fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Java SE Critical Patch Update Advisory. Zie de pagina JDK 8u144 Bug Fixes voor de volledige lijst met bugfixes in deze release.

» Opmerkingen bij release 8u144

Java 8 Update 141 (8u141)

Hoogtepunten van release

IANA Data 2017b
JDK 8u141 bevat IANA tijdzonegegevens, versie 2017b. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Certificaatwijzigingen: nieuwe certificaten voor Let's Encrypt toegevoegd aan startcertificeringsinstanties
Er is één nieuw startcertificaat toegevoegd:
ISRG Root X1 alias: letsencryptisrgx1 DN: CN=ISRG Root X1, O=Internet Security Research Group, C=US
JDK-8177539 (niet openbaar)
Diagnostische verbeteringen in JMX
com.sun.management.HotSpotDiagnostic::dumpHeap De API geeft nu IllegalArgumentException als resultaat als de opgegeven bestandsnaam niet eindigt met het suffix “.hprof”. Bestaande applicaties die geen bestandsnaam leveren die eindigt met de extensie “.hprof”, zullen mislukken met IllegalArgumentException als resultaat. In dat geval kunnen applicaties de uitzondering verwerken of het oude gedrag herstellen door de systeemeigenschap 'jdk.management.heapdump.allowAnyFileSuffix' op 'waar' in te stellen.
JDK-8176055 (niet openbaar)
Strakkere beveiligingscontrrole op verwerking van WSDL-bestanden door hulpprogramma wsimport
Het hulpprogramma wsimport is gewijzigd: DTD's in webservicebeschrijvingen zijn niet meer toegestaan. Specifiek:
- Declaratie DOCTYPE is niet toegestaan in documenten.
- Externe algemene entiteiten worden standaard niet opgenomen.
- Externe parameterentiteiten worden standaard niet opgenomen.
- Externe DTD's worden geheel genegeerd.
Ga als volgt te werk om het vroegere gedrag te herstellen:
- Stel de systeemeigenschap com.sun.xml.internal.ws.disableXmlSecurity in op 'waar'.
- Gebruik van de opdrachtregeloptie –disableXmlSecurity in het hulpprogramma wsimport
  Opmerking: de ondersteuning in JDK 7 en JDK 6 voor deze optie in wsimport wordt geleverd via een patch die na de CPU van juli wordt vrijgegeven.
JDK-8182054 (niet openbaar)
SNI-extensie geactiveerd door aangepaste HostnameVerifier
In eerdere releases van JDK 8-updates werd niet altijd de SNI-extensie (Server Name Indication) verzonden in de TLS-fase ClientHello als er een aangepaste hostnaamverificatie werd gebruikt. Deze verificatie wordt ingesteld via de methode setHostnameVerifier(HostnameVerifier v) in HttpsURLConnection. Door deze fix wordt de servernaam nu verstuurd in de hoofdtekst van 'ClientHello'.
Zie voor meer informatie: JDK-8144566.
Verbeterde controle op algoritmebeperkingen
Voor het beperken van het gebruik van zwakke algoritmen in situaties waarin deze het meest kwetsbaar zijn, zijn aanvullende functies toegevoegd voor het configureren van de beveiligingseigenschappen jdk.certpath.disabledAlgorithms en jdk.jar.disabledAlgorithms in het bestand java.security.
jdk.certpath.disabledAlgorithms: De meeste wijzigingen zijn aangebracht in de eigenschap 'certpath'. Voorheen was deze beperkt tot twee soorten beperkingen: volledige deactivering van een algoritme op naam of volledige deactivering van een algoritme op sleutelgrootte, bij het controleren van certificaten, certificaatketens en certificaathandtekeningen. Op deze manier worden er configuraties gemaakt die absoluut zijn en niet flexibel in het gebruik. Er zijn drie nieuwe beperkingen toegevoegd, zodat er meer flexibiliteit komt voor het toestaan en afwijzen van certificaten.

Met "jdkCA" wordt het beëindigen van de certificaatketen onderzocht met betrekking tot het bestand cacerts. In het geval van "SHA1 jdkCA" wordt het gebruik van SHA1 gecontroleerd via de certificaatketen, maar de keten wordt alleen afgewezen als deze eindigt bij een gemarkeerd vertrouwd anker in de sleutelopslag 'cacerts'. Dit is nuttig voor organisaties met een eigen privécertificeringsinstantie die het gebruik van SHA1 met hun vertrouwd anker vertrouwen, maar die het gebruik van SHA1 door certificaatketens die zijn verankerd door een openbare certificeringsinstantie, willen blokkeren.

Met "denyAfter" wordt gecontroleerd of de opgegeven datum eerder is dan de huidige datum of de datum van PKIXParameter. In het geval van "SHA1 denyAfter 2018-01-01" kan vóór 2018 een certificaat met SHA1 worden gebruikt. Na deze datum wordt het certificaat afgewezen. Dit kan worden gebruikt voor beleid in een organisatie die een algoritme uitfaseert met een drop-dead-datum. Voor ondertekende JAR-bestanden wordt de datum vergeleken met het TSA-tijdstempel. De datum wordt opgegeven in GMT.

Met "usage" wordt het opgegeven algoritme onderzocht voor een opgegeven gebruik. Dit kan worden gebruikt wanneer het niet handig is om een algoritme voor al het gebruik te deactiveren. Drie soorten gebruik kunnen worden opgegeven:
- 'TLSServer' beperkt het algoritme in TLS-servercertificaatketens wanneer serververificatie wordt uitgevoerd als client.
- 'TLSServer' beperkt het algoritme in TLS-clientcertificaatketens wanneer serververificatie wordt uitgevoerd als server.
- 'SignedJAR' beperkt de algoritmen in certificaten in ondertekende JAR-bestanden. Het gebruikstype volgt na het trefwoord. Als u meerdere gebruikstypen wilt opgeven, gebruikt u een witruimte als scheidingsteken.
  Voorbeeld: met "SHA1 usage TLSServer TLSClient" zijn SHA1-certificaten niet toegestaan voor TLSServer- en TLSClient-bewerkingen, maar zijn SignedJars wel toegestaan.
Voor het beperken van een algoritme kunnen al deze beperkingen worden gecombineerd met een '&' als scheidingsteken. Als u bijvoorbeeld SHA1-certificaatketens wilt deactiveren die alleen voor TLSServer-bewerkingen worden beëindigd bij gemarkeerde vertrouwde ankers, gebruikt u de beperking "SHA1 jdkCA & usage TLSServer".

jdk.jar.disabledAlgorithms: er is één beperking toegevoegd aan deze eigenschap van .jar om JAR-manifestalgoritmen te beperken.

Met "denyAfter" worden algoritmebeperkingen voor manifestoverzichtsalgoritmen in een ondertekend JAR-bestand gecontroleerd. De datum in de beperking wordt vergeleken met het TSA-tijdstempel op het ondertekende JAR-bestand. Als er geen tijdstempel is, of als het tijdstempel gelijk is aan of later is dan de opgegeven datum, wordt het ondertekende JAR-bestand behandeld als niet-ondertekend. Als het tijdstempel voor de opgegeven datum ligt, functioneert de .jar als ondertekend JAR-bestand. De syntaxis voor het beperken van SHA1 in JAR-bestanden die na 1 januari 2018 zijn ondertekend, luidt als volgt: "SHA1 denyAfter 2018-01-01". Dit is dezelfde syntaxis als voor de eigenschap certpath, met als verschil dat de certificaatcontrole niet wordt uitgevoerd door deze eigenschap.
Zie voor meer informatie: JDK-8176536.

Vervaldatum van Java

De vervaldatum voor 8u141 is 17 oktober 2017. Java verloopt wanneer een nieuwe release met oplossingen voor beveiligingsproblemen beschikbaar komt. Voor systemen die de Oracle servers niet kunnen bereiken, verloopt deze JRE (versie 8u141) door een secundair mechanisme op 17 november 2017. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), stuurt de JRE gebruikers aanvullende waarschuwingen en herinneringen om een update naar de nieuwere versie uit te voeren.

Bugfixes

Deze release bevat fixes voor beveiligingskwetsbaarheden zoals omschreven in Oracle Java SE Critical Patch Update Advisory. Zie de pagina JDK 8u141 Bug Fixes voor een volledigere lijst met bugfixes in deze release.

» Opmerkingen bij release 8u141

Java 8 Update 131 (8u131)

Hoogtepunten van release

IANA Data 2016j
JDK 8u131 bevat IANA tijdzonegegevens, versie 2016j. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Bugfix: introductie van nieuw model om vensters te ordenen
Op het OS X-platform gebruikte het AWT-framework native services om relaties tussen bovenliggende en onderliggende vensters te implementeren. Dat veroorzaakte ongewenste visuele effecten, vooral in omgevingen met meerdere beeldschermen. Om de nadelen van deze benadering op te heffen is het nieuwe model om vensters te ordenen geïntroduceerd. Dit is volledig geïmplementeerd in de JDK-laag. Hieronder worden de belangrijkste principes van het model genoemd:
- Een venster moet boven het meest nabije bovenliggende ('parent') venster worden geplaatst.
- Als een venster meerdere onderliggende ('child') vensters heeft, moeten deze in dezelfde laag liggen en het venster uit de keten actieve vensters moet in de volgorde voor de vensters van hetzelfde niveau worden geplaatst.
- Een venster moet niet worden geordend als het zich in 'iconified' toestand bevindt of wanneer er een transitie naar een 'iconified' toestand gaande is.
Deze regels worden toegepast op elk frame of dialoogvenster van de vensterhiërarchie dat het huidige venster in focus bevat. Zie voor meer informatie: JDK-8169589.
Bugfix: correctie van IllegalArgumentException door TLS-handshake
Een recent probleem van de JDK-8173783-fix kan een probleem veroorzaken voor sommige TLS-servers. Het probleem ontstaat door een IllegalArgumentException die wordt veroorzaakt door de TLS-handshakercode:

java.lang.IllegalArgumentException: Systeemeigenschap jdk.tls.namedGroups(null) bevat geen ondersteunde elliptische krommen.

Het probleem kan optreden wanneer de server geen ondersteuning heeft voor cryptografie met elliptische krommen, waarmee een eventueel naamextensieveld van een elliptische kromme kan worden verwerkt. Gebruikers kunnen het best een upgrade naar deze versie uitvoeren. Standaard worden JDK 7-updates en later JDK-versies geleverd met SunEC-beveiliging, die ondersteuning biedt voor cryptografie met elliptische krommen. Dit probleem is niet van invloed op die versies, tenzij beveiligingsproviders zijn gewijzigd. Zie voor meer informatie: JDK-8173783.
MD5 toegevoegd aan beveiligingseigenschap jdk.jar.disabledAlgorithms
In deze JDK-release wordt een nieuwe beperking voor de verificatie van met MD5 ondertekende JAR-bestanden geïntroduceerd. Als voor het ondertekende JAR-bestand gebruik wordt gemaakt van MD5, wordt bij de handtekeningverificatie de handtekening genegeerd en wordt het JAR-bestand behandeld alsof het niet ondertekend is. Dit treedt mogelijk op in de volgende typen applicaties die gebruikmaken van ondertekende JAR-bestanden:
- Applets of Web Start-toepassingen
- Zelfstandige applicaties of serverapplicaties worden uitgevoerd met een SecurityManager en zijn geconfigureerd met een policybestand waarmee rechten worden toegekend op basis van de codeondertekenaar(s) van het JAR-bestand.
De lijst van uitgeschakelde algoritmen wordt beheerd met de beveiligingseigenschap jdk.jar.disabledAlgorithms in het bestand java.security. Deze eigenschap bevat een lijst van uitgeschakelde algoritmen en sleutellengten voor cryptografisch ondertekende JAR-bestanden.

Als u wilt controleren of er een algoritme of sleutel is gebruikt om een JAR-bestand te ondertekenen, kunt u het binaire jarsigner-bestand gebruiken dat bij deze JDK wordt geleverd. Wanneer u "jarsigner -verify" uitvoert op een JAR-bestand dat is ondertekend met een zwak algoritme of zwakke sleutel, wordt meer informatie over het uitgeschakelde algoritme of de uitgeschakelde sleutel afgedrukt.

Als u bijvoorbeeld een JAR-bestand met de naam test.jar wilt controleren, gebruikt u de volgende opdracht:

jarsigner -verify test.jar

Als het bestand in dit voorbeeld is ondertekend met een zwak handtekeningalgoritme, bijvoorbeeld MD5withRSA, wordt de volgende uitvoer weergegeven:

Het JAR-bestand wordt behandeld als niet-ondertekend, omdat het is ondertekend met een zwak algoritme dat nu is gedeactiveerd. Voor meer details voert u jarsigner opnieuw uit met de optie -verbose.

Gebruik de optie -verbose om meer details weer te geven:

jarsigner -verify -verbose test.jar

Hiermee wordt de volgende uitvoer weergegeven:
```
 - 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 
```
Als u het probleem wilt verhelpen, moet u het JAR-bestand opnieuw ondertekenen met een sterker algoritme of een sterkere sleutellengte. U kunt de beperkingen ook ongedaan maken door het desbetreffende zwakke algoritme of de sleutellengte te verwijderen uit de beveiligingseigenschap jdk.jar.disabledAlgorithms; deze optie wordt echter niet aangeraden. Voordat de betrokken JAR-bestanden opnieuw worden ondertekend, moeten de bestaande handtekeningen uit het JAR-bestand worden verwijderd. Dit kan als volgt met het ziphulpprogramma:

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

Controleer regelmatig de planning voor Oracle JRE en JDK Cryptographic op http://java.com/cryptoroadmap voor geplande beperkingen op ondertekende JAR-bestanden en andere beveiligingsonderdelen. JDK-8171121 (niet openbaar)
Nieuwe systeemeigenschap om caching te regelen voor HTTP SPNEGO-verbindingen
Er is een nieuwe systeemeigenschap ingevoerd, specifiek voor de JDK-implementatie, om caching te regelen voor HTTP SPNEGO-verbindingen (Negotiate/Kerberos). Caching voor HTTP SPNEGO-verbindingen blijft standaard ingeschakeld. Als de eigenschap niet expliciet wordt opgegeven, zal het gedrag dus niet veranderen. Wanneer verbinding wordt gemaakt met een HTTP-server die SPNEGO gebruikt voor de verificatie, en wanneer verbinding en verificatie bij de server zijn geslaagd, worden de verificatiegegevens gecachet en hergebruikt voor latere verbindingen met dezelfde server. Bovendien wordt bij verbinding met een HTTP-server met SPNEGO de onderliggende verbinding meestal actief gehouden en hergebruikt voor latere aanvragen bij dezelfde server. Bij sommige applicaties kan het wenselijk zijn om alle caching voor het HTTP SPNEGO-protocol (Negotiate/Kerberos) te deactiveren zodat bij elke aanvraag bij de server een verificatieaanvraag wordt afgedwongen.

Met deze wijziging bieden we een nieuwe systeemeigenschap waarmee het cachingbeleid voor HTTP SPNEGO-verbindingen kan worden geregeld. Als jdk.spnego.cache wordt gedefinieerd en als 'niet waar' wordt geëvalueerd, wordt alle caching gedeactiveerd voor HTTP SPNEGO-verbindingen. Wanneer deze systeemeigenschap op 'niet waar' wordt ingesteld, kunnen er echter ongewenste neveneffecten optreden:
- De prestaties van HTTP SPNEGO-verbindingen kunnen sterk worden beïnvloed, omdat voor elke aanvraag nieuwe verificatie nodig is, zodat er verschillende communicatie-uitwisselingen met de server plaatsvinden.
- Voor alle nieuwe aanvragen moeten referenties worden opgehaald. Dit kan leiden, afhankelijk van of transparante verificatie al dan niet beschikbaar is, en afhankelijk van de algemene implementatie van de verificator, tot een pop-up waarin de gebruiker bij elke nieuwe aanvraag om referenties wordt gevraagd.
JDK-8170814 (niet openbaar)
Nieuwe systeemeigenschap om caching te regelen voor HTTP NTLM-verbindingen
Er is een nieuwe systeemeigenschap ingevoerd, specifiek voor de JDK-implementatie, om caching te regelen voor HTTP NTLM-verbindingen. Caching voor HTTP NTLM-verbindingen blijft standaard ingeschakeld. Als de eigenschap niet expliciet wordt opgegeven, zal het gedrag dus niet veranderen. Op sommige platforms kan de HTTP NTLM-implementatie in de JDK transparante verificatie ondersteunen, waarbij de systeemreferenties van de gebruiker worden gebruikt op systeemniveau. Wanneer transparante verificatie niet beschikbaar is of mislukt, ondersteunt de JDK alleen het ophalen van referenties bij een algemene verificator. Als de verbinding met de server is geslaagd, worden de verificatiegegevens gecachet en hergebruikt voor latere verbindingen met dezelfde server. Bovendien wordt bij verbinding met een HTTP NTLM-server de onderliggende verbinding meestal actief gehouden en hergebruikt voor latere aanvragen bij dezelfde server. Bij sommige applicaties kan het wenselijk zijn om alle caching voor het HTTP NTLM-protocol te deactiveren, zodat bij elke aanvraag bij de server een verificatieaanvraag wordt afgedwongen.

Met deze wijziging bieden we een nieuwe systeemeigenschap waarmee het cachingbeleid voor HTTP NTLM-verbindingen kan worden geregeld. Als jdk.ntlm.cache wordt gedefinieerd en als 'niet waar' wordt geëvalueerd, wordt alle caching gedeactiveerd voor HTTP NTLM-verbindingen. Wanneer deze systeemeigenschap op 'niet waar' wordt ingesteld, kunnen er echter ongewenste neveneffecten optreden:
- De prestaties van HTTP NTLM-verbindingen kunnen sterk worden beïnvloed, omdat voor elke aanvraag nieuwe verificatie nodig is, zodat er verschillende communicatie-uitwisselingen met de server plaatsvinden.
- Voor alle nieuwe aanvragen moeten referenties worden opgehaald. Dit kan leiden, afhankelijk van of transparante verificatie al dan niet beschikbaar is, en afhankelijk van de algemene implementatie van de verificator, tot een pop-up waarin de gebruiker bij elke nieuwe aanvraag om referenties wordt gevraagd.
JDK-8163520 (niet openbaar)
Nieuwe versie van VisualVM
VisualVM 1.3.9 is geïntroduceerd op 4 oktober 2016 http://visualvm.github.io/relnotes.html en is in 8u131 geïntegreerd. Zie voor meer informatie: JDK-8167485.

Vervaldatum van Java

De vervaldatum voor 8u131 is 18 juli 2017. Java verloopt wanneer een nieuwe release met oplossingen voor beveiligingsproblemen beschikbaar komt. Voor systemen die de Oracle servers niet kunnen bereiken, verloopt deze JRE (versie 8u131) door een secundair mechanisme op 18 augustus 2017. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), zal Java aanvullende waarschuwingen en herinneringen aan gebruikers sturen om een update naar de nieuwere versie uit te voeren.

Bugfixes

Deze release bevat fixes voor beveiligingsproblemen. Zie Oracle Java SE Critical Patch Update Advisory voor meer informatie. Zie de pagina JDK 8u131 Bug Fixes voor een lijst met bugfixes in deze release.

» Opmerkingen bij release 8u131

Java 8 Update 121 (8u121)

Hoogtepunten van release

IANA Data 2016i
JDK 8u121 bevat IANA tijdzonegegevens, versie 2016i. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Bugfix: Via trackpad schuiven van tekst gaat erg snel in OS X 10.12 Sierra.
De methode MouseWheelEvent.getWheelRotation() retourneerde afgeronde deltaX/Y-events via native NSEvent op Mac OS X. Op Mac OS Sierra 10.12 levert NSEvent deltaX/Y erg kleine waarden op. Het afronden en optellen van deze waarden leidt dus tot een heel grote geretourneerde waarde van MouseWheelEvent.getWheelRotation(). In de fix voor JDK-8166591 worden de waarden van NSEvent deltaX/Y geaccumuleerd en retourneert de methode MouseWheelEvent.getWheelRotation() alleen niet-nulwaarden als de geaccumuleerde waarde groter is dan nul en een drempel overschrijdt. Dit voldoet aan de specificatie van MouseWheelEvent.getWheelRotation(): "Retourneert het aantal 'klikken' dat het muiswiel is geroteerd als geheel getal. Een gedeeltelijke rotatie is mogelijk als de muis een wiel met hoge resolutie ondersteunt. De methode retourneert in dat geval nul totdat een volledige 'klik' is geaccumuleerd." Gebruik in plaats daarvan de methode MouseWheelEvent.getPreciseWheelRotation() als u de precieze wielrotatiewaarden wilt gebruiken. Zie voor meer informatie: JDK-8166591.
Verbeterde standaardsterkte van EC in JDK
Om de standaardsterkte van EC-cryptografie te verbeteren, zijn EC-sleutels van minder dan 224 bits gedeactiveerd in de verwerking van certificeringspaden (via de beveiligingseigenschap jdk.certpath.disabledAlgorithms) en SSL/TLS-verbindingen (via de beveilingseigenschap jdk.tls.disabledAlgorithms) in JDK. Deze beperking kan voor applicaties worden bijgewerkt in de beveiligingseigenschappen zodat kleinere sleutellengten zijn toegestaan (bijvoorbeeld "EC keySize < 192"). EC-curves van minder dan 256 bits worden verwijderd uit de SSL/TLS-implementatie in JDK. De nieuwe systeemeigenschap jdk.tls.namedGroups bevat een lijst met geactiveerde benoemde curves voor EC-coderingssuites in de volgorde van voorkeur. Als de standaard geactiveerde EC-curves of de voorkeuren voor curves voor een applicatie moeten worden gewijzigd, moet de systeemeigenschap dienovereenkomstig worden bijgewerkt. Bijvoorbeeld:
```
 jdk.tls.namedGroups="secp256r1, secp384r1, secp521r1" 
```
Op de standaard geactiveerde of aangepaste EC-curves zijn de algoritmebeperkingen van toepassing. EC-sleutels die in de Java-beveiligingseigenschappen zijn gedeactiveerd, kunnen bijvoorbeeld niet opnieuw worden geactiveerd via de aangepaste EC-curves. Zie voor meer informatie: JDK-8148516.
Nieuw: optie --allow-script-in-comments voor javadoc
In het javadoc-hulpprogramma wordt nu alle JavaScript-code in de javadoc-documentatie-opmerkingen en opdrachtregelopties afgewezen, tenzij de opdrachtregeloptie --allow-script-in-comments is opgegeven. Met de optie --allow-script-in-comments blijft alle JavaScript-code in documentatie-opmerkingen en opdrachtregelopties behouden in het javadoc-hulpprogramma. Er wordt een foutmelding gegeven door het javadoc-hulpprogramma als JavaScript-code is gevonden en de opdrachtregeloptie niet is ingesteld.
JDK-8138725 (niet openbaar)
De minimumsleutellengte verhogen naar 1024 voor XML-handtekeningen
De veilige validatiemodus van de implementatie voor XML-handtekeningen is verbeterd en beperkt nu standaard RSA- en DSA-sleutels die kleiner zijn dan 1024 bits, omdat deze niet veilig genoeg meer zijn voor digitale handtekeningen. Er is ook een nieuwe beveiligingseigenschap met de naam jdk.xml.dsig.SecureValidationPolicy toegevoegd aan het bestand java.security. Met deze eigenschap kunnen de verschillende beperkingen worden beheerd wanneer de veilige validatiemodus actief is. De beveiligde validatiemodus kan worden geactiveerd door de XML-handtekeningeigenschap org.jcp.xml.dsig.secureValidation in te stellen op 'Waar' met de methode javax.xml.crypto.XMLCryptoContext.setProperty of door de code uit te voeren met een SecurityManager. Als er een XML-handtekening wordt gegenereerd of gevalideerd met een zwakke RSA- of DSA-sleutel, wordt er een XMLSignatureException gegenereerd met het bericht "RSA keys less than 1024 bits are forbidden when secure validation is enabled" of "DSA keys less than 1024 bits are forbidden when secure validation is enabled" (RSA-sleutels respectievelijk DSA-sleutels die korter zijn dan 1024 bits zijn niet toegestaan als beveiligde validatie actief is).
JDK-8140353 (nniet openbaar)
Certificaten met DSA-sleutels die korter zijn dan 1024 bits beperken
DSA-sleutels die kleiner zijn dan 1024 bits zijn niet sterk genoeg en moeten worden beperkt bij het opbouwen van certificatiepaden en de validatie van certificaten. Door "DSA keySize < 1024" toe te voegen aan de beveiligingseigenschap "jdk.certpath.disabledAlgorithms", worden DSA-sleutels die kleiner zijn dan 1024 bits dus standaard gedeactiveerd. Deze beperking kan voor applicaties worden bijgewerkt in de beveiligingseigenschap ("jdk.certpath.disabledAlgorithms") zodat kleinere sleutellengten zijn toegestaan (bijvoorbeeld "DSA keySize < 768"). JDK-8139565 (niet openbaar)
Meer controles toegevoegd aan de ontleedcode voor DER-codering
Er zijn meer controles toegevoegd aan de ontleedcode voor DER-codering voor het vaststellen van diverse coderingsfouten. Bovendien leiden handtekeningen met geconstrueerde, oneindige-lengtecodering nu tot een IOException bij het ontleden. Deze wijziging is niet van invloed op handtekeningen die zijn gegenereerd met JDK-standaardproviders. JDK-8168714 (niet openbaar)
Aanvullende toegangsbeperkingen voor URLClassLoader.newInstance
Klassenlaadprogramma's die zijn gemaakt met de methode java.net.URLClassLoader.newInstance kunnen worden gebruikt om klassen te laden uit een lijst met opgegeven URL's. Als de aanroepcode geen toegang heeft tot een of meer van de URL's, en de toegankelijke URL-artefacten niet de vereiste klasse bevatten, wordt er een ClassNotFoundException of soortgelijke uitzondering gegenereerd. Voorheen werd er bij geweigerde URL-toegang een SecurityException gegenereerd. Als de oude situatie moet worden hersteld, kan deze wijziging worden gedeactiveerd door de systeemeigenschap jdk.net.URLClassPath.disableRestrictedPermissions in te stellen. JDK-8151934 (niet openbaar)
Een nieuwe configureerbare eigenschap in logging.properties java.util.logging.FileHandler.maxLocks
Een nieuwe configureerbare eigenschap, "java.util.logging.FileHandler.maxLocks", is toegevoegd aan java.util.logging.FileHandler. Deze nieuwe eigenschap voor loggen kan worden gedefinieerd in het configuratiebestand voor loggen. Met deze eigenschap kan het maximum aantal simultane logbestandvergrendelingen worden geconfigureerd dat een FileHandler kan verwerken. De standaardwaarde is 100. In een situatie met veel simultane verwerking waarin meerdere (meer dan 101) zelfstandige clientapplicaties gelijktijdig gebruikmaken van de API 'JDK Logging' en de FileHandler, is het mogelijk dat de standaardlimiet van 100 wordt behaald. Hierdoor kunnen bestanden niet worden vergrendeld door de FileHandler en wordt er een IOException gegenereerd. In dergelijke gevallen kan met de nieuwe eigenschap voor loggen het maximum aantal vergrendelingen worden verhoogd voordat de applicatie wordt geïmplementeerd. De standaardwaarde van maxLocks (100) blijft ongewijzigd, tenzij deze wordt overschreven. Raadpleeg de documentatie voor de API's java.util.logging.LogManager en java.util.logging.FileHandler voor meer details. Zie voor meer informatie: JDK-8153955.

Opmerkingen

Verbeterde beveiliging voor het extern laden van klassen via JNDI

Het extern laden van klassen via JNDI-objectfactory's die zijn opgeslagen in naam- en directoryservices is standaard gedeactiveerd. Als u het extern laden van klassen door de RMI-registratie- of COS-naamserviceprovider wilt inschakelen, stelt u de volgende systeemeigenschap in op de tekenreeks "waar", waar van toepassing:


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

JDK-8158997 (niet openbaar)

Met 'jarsigner -verbose -verify' worden de algoritmen afgedrukt voor het ondertekenen van het JAR-bestand.

Het hulpprogramma Jarsigner is verbeterd en toont nu details van de algoritmen en sleutels die worden gebruikt om een ondertekend JAR-bestand te genereren. Bovendien geeft het hulpprogramma een indicatie als een algoritme of sleutel zwak wordt bevonden.

Om precies te zijn, als "jarsigner -verify -verbose filename.jar" wordt aangeroepen, wordt er een afzonderlijke sectie afgedrukt met informatie over de handtekening en tijdstempel (indien aanwezig) in het ondertekende JAR-bestand, zelfs als het bestand om diverse redenen wordt behandeld als niet ondertekend. Als een algoritme of sleutel als zwak wordt beschouwd, zoals opgegeven in de beveiligingseigenschap jdk.jar.disabledAlgorithms wordt hieraan het label "(weak)" toegekend.

Bijvoorbeeld:


 - 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

Zie voor meer informatie: JDK-8163304.

Bekende problemen

Met javapackager en fx\:deploy wordt de hele JDK gebundeld in plaats van de JRE.

Er is een bekende bug in het Java-verpakkingsprogramma voor Mac waarbij de hele JDK wordt gebundeld met de applicatie. Dit leidt tot een ongewoon grote bundel. De tijdelijke oplossing is om de bundleroptie -Bruntime te gebruiken. Bijvoorbeeld: -Bruntime=JavaAppletPlugin.plugin waarbij JavaAppletPlugin.plugin voor de te bundelen JRE zich in de huidige directory bevindt. Zie voor meer informatie: JDK-8166835.

De installatie van Java mislukt voor niet-beheerders als UAC is uitgeschakeld.

De installatie van Java op Windows mislukt voor niet-beheerders, zonder waarschuwing en zonder te vragen, als gebruikerstoegangsbeheer (UAC) is uitgeschakeld. Het installatieprogramma maakt een directory, jds<nummer>.tmp, in de directory%TEMP%.
JDK-8161460 (niet openbaar)

Nieuwe functies

Toegevoegde beveiligingseigenschap voor configuratie van veilige validatiemodus voor XML-handtekeningen

Er is een nieuwe beveiligingseigenschap met de naam jdk.xml.dsig.secureValidationPolicy toegevoegd. Hiermee kunt u de afzonderlijke beperkingen configureren die worden afgedwongen als de veilige validatiemodus voorXML-handtekeningen actief is. De standaardwaarde voor deze eigenschap in het configuratiebestand java.security is:


 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

Zie de definitie van de eigenschap in het bestand java.security voor meer informatie. Zie voor meer informatie: JDK-8151893.

Serialisatiefilterconfiguratie

'Serialisatiefilter' is een nieuw mechanisme waarmee inkomende gegevensstromen voor objectserialisatie kunnen worden gefilterd voor een verbeterde beveiliging en stabielere werking. Indien geconfigureerd, wordt tijdens het deserialiseren bij elke ObjectInputStream een filter toegepast op de inhoud van de stroom. Filters kunnen worden ingesteld via een systeemeigenschap of een geconfigureerde beveiligingseigenschap. De waarde van de "jdk.serialFilter"-patronen wordt beschreven in JEP 290 Serialization Filtering en in <JRE>/lib/security/java.security. Filteracties worden gelogd naar het 'java.io.serialization'-logprogramma, indien geactiveerd. Zie voor meer informatie: JDK-8155760.

Verbeterde controle van beperkingen bij RMI

Het RMI-register en gedistribueerd opschonen van het geheugen maken gebruik van de mechanismen van JEP 290 Serialization Filtering voor een stabielere werking van de service. Bij het RMI-register en gedistribueerd opschonen van het geheugen worden ingebouwde wittelijst-filters geïmplementeerd voor de normale klassen die waarschijnlijk bij elke service worden gebruikt. Aanvullende filterpatronen kunnen worden geconfigureerd via een systeemeigenschap of een geconfigureerde beveiligingseigenschap. De patroonsyntaxis voor de eigenschappen "sun.rmi.registry.registryFilter" en "sun.rmi.transport.dgcFilter" wordt beschreven in JEP 290 en in <JRE>/lib/security/java.security. JDK-8156802 (niet openbaar)

Mechanisme toevoegen om toe te staan dat startcerticiferingsinstanties niet vallen onder algoritmebeperkingen.

In het bestand java.security is een extra beperking met de naam "jdkCA" toegevoegd aan de methode jdk.certpath.disabledAlgorithms. Deze beperking schakelt het opgegeven algoritme alleen uit als het algoritme gebruikt wordt in een certificaatketen die eindigt in een gemarkeerd vertrouwd anker in de sleutelopslag lib/security/cacerts. Als de beperking jdkCA niet is ingesteld, worden alle ketens beperkt die het opgegeven algorimte gebruiken. jdkCA kan slechts één keer worden gebruikt in een DisabledAlgorithm-uitdrukking. Voorbeeld: om deze beperking toe te passen op SHA-1-certificaten, neemt u het volgende op: SHA1 jdkCA
Zie JDK-8140422

Vervaldatum van Java

De vervaldatum voor 8u121 is 18 april 2017. Java verloopt wanneer een nieuwe release met oplossingen voor beveiligingsproblemen beschikbaar komt. Voor systemen die de Oracle servers niet kunnen bereiken, verloopt deze JRE (versie 8u121) door een secundair mechanisme op 18 mei 2017. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), zal Java aanvullende waarschuwingen en herinneringen aan gebruikers sturen om een update naar de nieuwere versie uit te voeren.

Bugfixes

Deze release bevat fixes voor beveiligingsproblemen. Zie Oracle Java SE Critical Patch Update Advisory voor meer informatie. Zie de pagina JDK 8u121 Bug Fixes voor een lijst met bugfixes in deze release.

» Opmerkingen bij release 8u121

Java 8 Update 111 (8u111)

Hoogtepunten van release

IANA Data 2016f
JDK 8u111 bevat IANA tijdzonegegevens, versie 2016f. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie. Zie voor meer informatie: JDK-8159684.
Certificaatwijzigingen: nieuwe startcertificeringsinstantie voor JCE-codeondertekening
Voor de ondersteuning van langere sleutellengten en sterkere hantekening-algoritmen is een nieuwe startcertificeringsinstantie voor codeondertekening voor JCE-providers gemaakt en het betreffende certificaat is toegevoegd aan Oracle JDK. Nieuwe certifcaten voor codeondertekening voor JCE-providers die door deze certificeringsinstantie zijn uitgegeven, worden vanaf nu gebruikt om JCE-providers te ondertekenen. Standaard worden nieuwe aanvragen voor certificaten voor codeondertekening voor JCE-providers uitgegeven vanuit deze certificeringsinstantie.

Bestaande certificaten van de huidige startcertificeringsinstantie voor codeondertekening voor JCE-providers worden nog wel gevalideerd. Deze startcertificeringsinstantie kan echter in de toekomst worden uitgeschakeld. Wij raden u aan om nieuwe certificaten aan te vragen en bestaande JAR-bestanden van providers opnieuw te ondertekenen. Voor meer informatie over het ondertekeningsproces voor JCE-providers raadpleegt u in de documentatie How to Implement a Provider in the Java Cryptography Architecture. JDK-8141340 (niet openbaar)
Services in menu Service
Het levensduurbeheer van AWT-menucomponenten leidde op bepaalde platforms tot problemen. Met deze fix wordt de statussynchronisatie tussen menu's en hun containers verbeterd. JDK-8158993 (niet openbaar)
Basisverificatie voor HTTPS-tunneling uitschakelen
In sommige omgevingen kunnen bepaalde verificatieschema's ongewenst zijn wanneer een HTTPS-proxy wordt gebruikt. Daarom is het basisverificatieschema standaard gedeactiveerd in Oracle Java Runtime, door Basic toe te voegen aan de netwerkeigenschap jdk.http.auth.tunneling.disabledSchemes. Proxy's waarvoor het verificatietype Basic vereist is bij het instellen van een tunnel voor HTTPS, zullen niet meer standaard succesvol zijn. Dit verificatieschema kan, indien nodig, opnieuw worden geactiveerd door Basic te verwijderen uit de netwerkeigenschap jdk.http.auth.tunneling.disabledSchemes of door een systeemeigenschap met dezelfde naam op de opdrachtregel in te stellen op "" (leeg). Bovendien kunnen de netwerkeigenschappen jdk.http.auth.tunneling.disabledSchemes en jdk.http.auth.proxying.disabledSchemes en de systeemeigenschappen met dezelfde naam worden gebruikt voor het uitschakelen van andere verificatieschema's die mogelijk actief zijn bij het instellen van een tunnel voor HTTPS of, respectievelijk, het proxyen van HTTP. JDK-8160838 (niet openbaar)
JAR-bestanden die zijn ondertekend met zwakke algoritmen en sleutels beperken
In deze JDK-release worden nieuwe beperkingen voor de verificatie van ondertekende JAR-bestanden geïntroduceerd. Als voor het ondertekende JAR-bestand gebruik wordt gemaakt van een uitgeschakeld algoritme of een sleutellengte die kleiner is dan de minimumlengte, wordt bij de handtekeningverificatie de handtekening genegeerd en wordt het JAR-bestand behandeld alsof het niet is ondertekend. Dit treedt mogelijk op in de volgende typen applicaties die gebruikmaken van ondertekende JAR-bestanden:
1. Applets of Web Start-toepassingen
2. Zelfstandige applicaties of serverapplicaties worden uitgevoerd met een SecurityManager en zijn geconfigureerd met een policybestand waarmee rechten worden toegekend op basis van de codeondertekenaar(s) van het JAR-bestand.

De lijst van uitgeschakelde algoritmen wordt beheerd met een nieuwe beveiligingseigenschap jdk.jar.disabledAlgorithms in het bestand java.security. Deze eigenschap bevat een lijst van uitgeschakelde algoritmen en sleutellengten voor cryptografisch ondertekende JAR-bestanden.

De volgende algoritmen en sleutellengten zijn beperkt in deze release:
1. MD2 (in het overzichts- of handtekening-algoritme)
2. RSA-sleutels korter dan 1024 bits
OPMERKING: we zijn van plan om op MD5 gebaseerde handtekeningen te beperken in ondertekende JAR-bestanden in de CPU-release van april 2017.

Als u wilt controleren of er een algoritme of sleutel is gebruikt om een JAR-bestand te ondertekenen, kunt u het binaire jarsigner-bestand gebruiken dat bij deze JDK wordt geleverd. Wanneer u jarsigner -verify -J-Djava.security.debug=jar uitvoert op een JAR-bestand dat is ondertekend met een zwak algoritme of zwakke sleutel, wordt meer informatie over het uitgeschakelde algoritme of de uitgeschakelde sleutel afgedrukt.

Als u bijvoorbeeld een JAR-bestand met de naam test.jar wilt controleren, gebruikt u de volgende opdracht:
jarsigner -verify -J-Djava.security.debug=jar test.jar

Als het bestand in dit voorbeeld is ondertekend met een zwak algoritme, zoals MD2withRSA, wordt de volgende uitvoer weergegeven:
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!

De bijgewerkte jarsigner-opdracht wordt afgesloten en de volgende waarschuwing wordt afgedrukt in de standaarduitvoer:
"Handtekening kan niet worden ontleed of geverifieerd. Het JAR-bestand wordt behandeld als niet-ondertekend. Mogelijk is het JAR-bestand ondertekend met een zwak algoritme dat nu uitgeschakeld is. Als u meer informatie wilt, voert u jarsigner opnieuw uit terwijl debuggen actief is (-J-Djava.security.debug=jar)"

Om het probleem te verhelpen, moet u het JAR-bestand opnieuw ondertekenen met een sterker algoritme of een sterkere sleutellengte. U kunt de beperkingen ook ongedaan maken door het desbetreffende zwakke algoritme of de sleutellengte te verwijderen uit de beveiligingseigenschap jdk.jar.disabledAlgorithms; deze optie wordt echter niet aangeraden. Voordat de betrokken JAR-bestanden opnieuw worden ondertekend, moeten de bestaande handtekeningen worden verwijderd uit het JAR-bestand. Dit kan als volgt met het hulpprogramma zip:

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

Controleer regelmatig de planning voor Oracle JRE en JDK Cryptographic op http://java.com/cryptoroadmap voor geplande beperkingen op ondertekende JAR-bestanden en andere beveiligingsonderdelen. Het huidige plan is om op MD5 gebaseerde handtekeningen te beperken in ondertekende JAR-bestanden in de CPU-release van april 2017.

U kunt testen of uw JAR-bestanden zijn ondertekend met MD5, door MD5 toe te voegen aan de beveiligingseigenschap jdk.jar.disabledAlgorithms, bijv.:

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

en vervolgens jarsigner -verify -J-Djava.security.debug=jar uit te voeren op uw JAR-bestanden, zoals hierboven beschreven.
JDK-8155973 (niet openbaar)
Waarschuwingsbericht toegevoegd aan dialoogvenster voor implementatieverificator
Er is een waarschuwingsbericht toegevoegd aan het verificatievenster van de plugin voor die gevallen waarin HTTP-basisverificatie wordt gebruikt (referenties worden niet-gecodeerd verzonden) terwijl een proxy wordt gebruikt of waarin geen SSL-/TLS-protocollen worden gebruikt:
"WAARSCHUWING: met het basisverificatieschema worden uw referenties verzonden als gewone tekst. Weet u het zeker?"
JDK-8161647 (niet openbaar)

Bekende problemen

Enkele events zijn niet beschikbaar in JFR-opnamen onder Windows.

De volgende events zijn in release 8u111 niet beschikbaar in JFR-opnamen onder Windows:

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

De oorzaak hiervan is de regressieve JDK-8063089 die is geïntroduceerd in 8u111 met de wijzigingen voor JDK-8162419. De oplossing voor JDK-8063089 kon niet worden opgenomen in release 8u111. Deze zal beschikbaar zijn in de volgende 8u111 BPR build en in de volgende openbare release.
JDK-8063089 (niet openbaar)

JVM geeft NullPointerExceptions op macOS Sierra 10.12

Als op macOS Sierra 10.12 een gebruiker op een modificatietoets drukt (zoals Command, Shift of Alt) terwijl een applet in een browser wordt uitgevoerd, kan een foutvenster met de naam "Interne fout" worden weergegeven. In het dock van macOS wordt ook het "exec"-pictogram weergegeven. De gebruiker kan de applet sluiten of proberen de applet opnieuw uit te voeren zonder op een modificatietoets te drukken. Zie voor meer informatie: JDK-8165867.

Vervaldatum van Java

De vervaldatum voor 8u111 is 17 januari 2017. Java verloopt wanneer een nieuwe release met oplossingen voor beveiligingsproblemen beschikbaar komt. Voor systemen die de Oracle servers niet kunnen bereiken, verloopt deze JRE (versie 8u111) door een secundair mechanisme op 17 februari 2017. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), zal Java aanvullende waarschuwingen en herinneringen aan gebruikers sturen om een update naar de nieuwere versie uit te voeren.

Bugfixes

Deze release bevat fixes voor beveiligingsproblemen. Zie Oracle Java SE Critical Patch Update Advisory voor meer informatie. Zie de pagina JDK 8u111 Bug Fixes voor een lijst met bugfixes in deze release.

» Opmerkingen bij release 8u111

Java 8 Update 101 (8u101)

Hoogtepunten van release

IANA Data 2016d
JDK 8u101 bevat IANA tijdzonegegevens, versie 2016d. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie. Zie voor meer informatie: JDK-8151876.
Certificaatwijzigingen
Er zijn nieuwe DTrust-certificaten toegevoegd aan startcertificeringsinstanties.
Er zijn twee nieuwe startcertificaten toegevoegd:
- 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
Zie voor meer informatie: JDK-8153080.

Er zijn nieuwe identiteitscertificaten toegevoegd aan startcertificeringsinstanties.
Er zijn drie nieuwe startcertificaten toegevoegd:
- 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.
Zie voor meer informatie: JDK-8154757.

Comodo-certificaat voor startcertificeringsinstantie is verwijderd.
Het Comodo-certificaat voor de startcertificeringsinstantie 'UTN - DATACorp SGC' is uit het bestand cacerts verwijderd. Zie voor meer informatie: JDK-8141540.

Sonera Class1 CA is verwijderd.
Het certificaat voor de startcertificeringsinstantie "Sonera Class1 CA" is uit het bestand cacerts verwijderd. Zie voor meer informatie: JDK-8141276.
Toegangsbeheer voor javax.rmi.CORBA.ValueHandler verbeteren
De klasse javax.rmi.CORBA.Util biedt methoden die kunnen worden gebruikt in stubs en verbindingen voor het uitvoeren van algemene bewerkingen. Deze klasse kan ook worden gebruikt als factory voor ValueHandlers. De interface javax.rmi.CORBA.ValueHandler bevat services voor het lezen en schrijven van waardetypen voor GIOP-stromen. De beveiliging van deze hulpprogramma's is verbeterd met het nieuwe toegangsrecht java.io.SerializablePermission("enableCustomValueHandler"). Dit wordt gebruikt om een vertrouwensrelatie tot stand te brengen tussen de gebruikers van de API's javax.rmi.CORBA.Util en javax.rmi.CORBA.ValueHandler.

Het vereiste toegangsrecht is het serialiseerbare toegangsrecht "enableCustomValueHanlder". Code van derden die wordt uitgevoerd met een SecurityManager maar zonder het nieuwe toegangsrecht, zal bij het aanroepen van Util.createValueHandler() mislukken met een AccessControlException.

Dit gedrag voor controle van toegangsrechten kan in JDK8u en eerdere releases worden overschreven door de systeemeigenschap "jdk.rmi.CORBA.allowCustomValueHandler" te definiëren.

Daarom is voor externe applicaties waarmee expliciet javax.rmi.CORBA.Util.createValueHandler wordt aangeroepen, een configuratiewijziging nodig als een SecurityManager is geïnstalleerd en aan geen van de volgende vereisten wordt voldaan:
1. Het toegangsrecht java.io.SerializablePermission("enableCustomValueHandler") wordt niet verleend door SecurityManager.
2. Als applicaties worden uitgevoerd onder JDK8u of lager, is de systeemeigenschap "jdk.rmi.CORBA.allowCustomValueHandler" niet gedefinieerd, of gedefinieerd met een waarde die gelijk is aan "false" (hoofdletterongevoelig).
De typfout "enableCustomValueHanlder" wordt gecorrigeerd in de releases van oktober 2016. In die releases en toekomstige JDK-releases is "enableCustomValueHandler" het juiste serialisatietoegangsrecht.
JDK-8079718 (niet openbaar)
Ondersteuning toegevoegd in jarsigner voor opgeven van tijdstempel-hash-algoritme
Er is een nieuwe optie -tsadigestalg toegevoegd aan jarsigner om het berichtoverzichtsalgoritme op te geven waarmee de berichttekst wordt verstuurd naar de TSA-server. In oudere JDK-releases werd het overzichtsalgoritme SHA-1 gebruikt. Als deze nieuwe optie niet is opgegeven, wordt SHA-256 gebruikt in JDK 7 updates en latere JDK-versies. In JDK 6 updates blijft SHA-1 de standaardwaarde, maar er wordt een waarschuwing afgedrukt voor de standaarduitvoerstroom. Zie voor meer informatie: JDK-8038837.
In MSCAPI KeyStore kunnen meerdere certificaten met dezelfde naam worden afgehandeld.
Certificaten met dezelfde aliassen zijn niet toegestaan voor Java SE KeyStore. In Windows mogen meerdere certificaten die in één sleutelopslag zijn opgeslagen, niet-unieke gebruiksvriendelijke namen hebben. Met de oplossing voor JDK-6483657 is het mogelijk om bewerkingen uit te voeren op certificaten met niet-unieke namen door de zichtbare aliassen kunstmatig uniek te maken via de Java-API. Met deze oplossing is het niet mogelijk om certificaten met dezelfde naam te maken via de Java-API. Deze oplossing is alleen geschikt voor certificaten met dezelfde naam die aan de sleutelopslag zijn toegevoegd via hulpprogramma's van derden. Het is desondanks raadzaam om niet meerdere certificaten met dezelfde naam te gebruiken in uw ontwerp. Met name de volgende zin wordt niet verwijderd uit de Java-documentatie:
"Om problemen te voorkomen, is het raadzaam om in een KeyStore geen aliassen te gebruiken die alleen qua hoofdlettergebruik verschillen."
Zie voor meer informatie: JDK-6483657.
Met implementatietoolkit-API-methoden wordt geen JRE meer geïnstalleerd
Met de implementatietoolkit-API-methoden installLatestJRE() en installJRE(requestedVersion) van deployJava.js en de methode install() van dtjava.js wordt de JRE niet meer geïnstalleerd. Als de Java-versie van een gebruiker onder de beveiligingsbasislijn ligt, wordt de gebruiker omgeleid naar java.com om een bijgewerkte JRE te downloaden. JDK-8148310 (niet openbaar)
In DomainCombiner wordt runtimebeleid niet meer geraadpleegd voor statische ProtectionDomain-objecten bij het combineren van ProtectionDomain-objecten
In applicaties waarin statische ProtectionDomain-objecten (gemaakt met de 2-arg-constructor) worden gebruikt met onvoldoende toegangsrechten, treedt nu mogelijk een AccessControlException op bij deze fix. Hierin moeten de statische ProtectionDomain-objecten worden vervangen door dynamische objecten (met de 4-arg-constructor) waarvan de toegangsrechten worden uitgebreid met de huidige policy, of moet het statische ProtectionDomain-object worden opgebouwd met alle benodigde toegangsrechten. JDK-8147771 (niet openbaar)

Bekende problemen

JRE 8u101 wordt niet herkend in Internet Explorer (IE) als een statische-klasse-ID wordt gebruikt.

Als een applet of Web Start-applicatie wordt opgestart met een statische-klasse-ID en JRE 8u101 wordt gebruikt, wordt een ongewenst dialoogvenster weergegeven met de melding dat de gebruiker de laatste JRE moet gebruiken of het opstarten moet annuleren, ook al is de laatste JRE (JRE 8u101) geïnstalleerd en in gebruik. Dit specifieke probleem doet zich alleen voor in Windows en IE.

U wordt afgeraden statische-klasse-ID's te gebruiken voor selectie van de JRE-versie (sinds JDK 5u6, december 2005) volgens http://www.oracle.com/technetwork/java/javase/family-clsid-140615.html.

Gebruikers kunnen een van de volgende twee tijdelijke oplossingen gebruiken:

'Opstarten' kiezen en de waarschuwing negeren als de laatste versie (8u101) is geïnstalleerd
JRE 8u102 installeren, in plaats van JRE 8u101, om het probleem te vermijden

Ontwikkelaars kunnen een van de volgende twee dingen doen om dit probleem op te lossen:

Een dynamische-klasse-ID gebruiken in plaats van een statische-klasse-ID
Java_version gebruiken bij gebruik van een HTML-applet, of een JNLP-descriptor bij gebruik van JNLP

JDK-8147457 (niet openbaar)

Bugfixes

Deze release bevat fixes voor beveiligingsproblemen. Zie Oracle Java SE Critical Patch Update Advisory voor meer informatie. Zie de pagina JDK 8u101 Bug Fixes voor een lijst met bugfixes in deze release.

Vervaldatum van Java

De vervaldatum voor 8u101 is 19 oktober 2016. Java verloopt wanneer een nieuwe release met oplossingen voor beveiligingsproblemen beschikbaar komt. Voor systemen die de Oracle servers niet kunnen bereiken, verloopt deze JRE (versie 8u101) door een secundair mechanisme op 19 november 2016. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), zal Java aanvullende waarschuwingen en herinneringen aan gebruikers sturen om een update naar de nieuwere versie uit te voeren.

» Opmerkingen bij release 8u101

Java 8 Update 91 (8u91)

Hoogtepunten van release

IANA Data 2016a
JDK 8u91 bevat IANA tijdzonegegevens, versie 2016a. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Bugfix: achteruitgang van opstarttijd applet opgelost.
JDK-8080977 leidde tot vertraging bij het opstarten van de applet. De vertraging doet zich alleen voor in IE en duurt ongeveer 20 seconden. Deze vertraging is met JDK-8136759 verholpen. Zie voor meer informatie: JDK-8136759.
Bugfix: genereren van DSA handtekening wordt nu onderworpen aan controle van de sleutelsterkte
Als voor het genereren van de handtekening de beveiliging van het overzichtalgoritme minder sterk is dan de beveiliging van de sleutel die wordt gebruikt om de handtekening te ondertekenen (bijvoorbeeld (2048, 256)-bits DSA sleutels gebruiken voor SHA1withDSA handtekening), mislukt de bewerking met de foutmelding: 'De beveiliging van het SHA1 overzichtalgoritme is niet sterk genoeg voor deze sleutelgrootte'. JDK-8138593 (niet openbaar)
Bugfix: probleem met Firefox 42 LiveConnect
Omdat de browser erdoor kan vastlopen, worden JavaScript-naar-Java aanroepen niet verwerkt wanneer de Java-plug-in is gestart vanuit plugin-container.exe (standaardgedrag voor Firefox 42) en de status van de applet niet Gereed (2) is. Als de applet niet gereed is (de status is niet 2), wordt de feitelijke Java-methode niet uitgevoerd en wordt alleen NULL geretourneerd.

Als de plug-in is gestart vanuit plugin-container.exe, kunt u beter geen JavaScript-naar-Java aanroepen gebruiken die mogelijk meer dan 11 seconden in beslag nemen (de standaardwaarde voor dom.ipc.plugins.hangUITimeoutSecs) voordat ze zijn voltooid of een modaal dialoogvenster weergeven tijdens de JavaScript-naar-Java aanroep. In dit geval moet de hoofdthread voor de browser worden geblokkeerd, waardoor de browser kan vastlopen en de plug-in kan worden beëindigd.

Tijdelijke oplossing voor Firefox 42: gebruikers kunnen dom.ipc.plugins.enabled=false instellen. Een nadeel van deze tijdelijke oplossing is dat hierdoor de instelling voor alle plug-ins wordt gewijzigd. JDK-8144079 (niet openbaar)
Bugfix: nieuw attribuut voor JMX RMI JRMP servers, waarmee een lijst met klassenamen wordt opgegeven die kan worden gebruikt voor het deserialiseren van serverreferenties
Er is een nieuw Java-attribuut gedefinieerd voor de omgeving waardoor een JMX RMI JRMP server een lijst met klassenamen kan opgeven. Deze namen stemmen overeen met de gesloten groep klassenamen die door de server worden verwacht bij het deserialiseren van referenties. Als bijvoorbeeld de verwachte referenties bestonden uit
```
 List<string>
```
dan zou de gesloten groep uit alle concrete klassen bestaan die kunnen worden verwacht in de seriële vorm van een lijst Strings.

Standaard wordt dit attribuut alleen gebruikt door de standaardagent in het volgende geval:
```
 { "[Ljava.lang.String;", "java.lang.String" } 
```
Alleen arrays van Strings en Strings worden geaccepteerd bij het deserialiseren van referenties. De attribuutnaam is:
```
"jmx.remote.rmi.server.credential.types" 
```
Hier volgt een voorbeeld van een gebruiker die een server start met de opgegeven referenties en klassenamen:
```
 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); 
```
De nieuwe functie moet worden gebruikt door de volgende code rechtstreeks op te geven:
"jmx.remote.rmi.server.credential.types"

JDK-8144430 (niet openbaar)
Bugfix: MD5withRSA handtekening-algoritme deactiveren in de JSSE provider
Het MD5withRSA handtekening-algoritme wordt nu als onveilig beschouwd en dient niet langer te worden gebruikt. Daarom is ook MD5withRSA standaard gedeactiveerd in de JSSE implementatie van Oracle door 'MD5withRSA' toe te voegen aan de beveiligingseigenschap 'jdk.tls.disabledAlgorithms'. Nu worden zowel TLS handshakeberichten als X.509 certificaten die zijn ondertekend met het MD5withRSA algoritme, niet langer standaard geaccepteerd. Door deze wijziging wordt de eerdere op MD5 gebaseerde certificaatbeperking ('jdk.certpath.disabledAlgorithms') uitgebreid met handshakeberichten in TLS versie 1.2. Indien dat vereist is, kan dit algoritme opnieuw worden geactiveerd door 'MD5withRSA' te verwijderen uit de beveiligingseigenschap 'jdk.tls.disabledAlgorithms'. JDK-8144773 (niet openbaar)
Bugfix: nieuwe certificaten toevoegen aan startcertificeringsinstanties
Acht nieuwe startcertificaten zijn toegevoegd:
- 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
Zie JDK-8145954 en JDK-8145955.

Opmerkingen

Verwijdering van statische JRE's
In Java-installatieprogramma's voor Windows ouder dan versie 8u91 worden geïnstalleerde JRE's niet standaard verwijderd. Om statisch geïnstalleerde JRE's te verwijderen, moesten gebruikers deze handmatig selecteren in de gebruikersinterface van het Java-installatieprogramma. In Java release 8u91 en hoger worden statisch geïnstalleerde JRE's automatisch verwijderd als ze onder de beveiligingsbasislijn vallen. Zie Java Runtime Environment Configuration voor meer informatie over statische installaties.

Vervaldatum van Java

De vervaldatum voor 8u91 is 19 juli 2016. Java verloopt wanneer een nieuwe release met oplossingen voor beveiligingsproblemen beschikbaar komt. Voor systemen die de Oracle Servers niet kunnen bereiken, verloopt deze JRE (versie 8u91) door een secundair mechanisme op 19 augustus 2016. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), zal Java aanvullende waarschuwingen en herinneringen aan gebruikers sturen om een update naar de nieuwere versie uit te voeren.

Bugfixes

Deze release bevat fixes voor beveiligingsproblemen. Zie Oracle Java SE Critical Patch Update Advisory voor meer informatie. Zie de pagina JDK 8u91 Bug Fixes voor een lijst met bugfixes in deze release.

» Opmerkingen bij release 8u91

Java 8 Update 77 (8u77)

Hoogtepunten van release

IANA Data 2016a
JDK 8u77 bevat IANA-tijdzonegegevens, versie 2016a. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.

Vervaldatum van Java

De vervaldatum voor 8u77 is 19 april 2016. Java verloopt wanneer een nieuwe release met oplossingen voor beveiligingsproblemen beschikbaar komt. Voor systemen die de Oracle servers niet kunnen bereiken, verloopt deze JRE (versie 8u77) door een secundair mechanisme op 19 mei 2016. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), zal Java aanvullende waarschuwingen en herinneringen aan gebruikers sturen om een update naar de nieuwere versie uit te voeren.

Opmerkingen

De beveiligingswaarschuwing (8u77) is gebaseerd op de eerdere release 8u74 PSU. Alle gebruikers van eerdere JDK 8-releases moeten hun versie bijwerken naar deze release. Raadpleeg voor meer informatie over het verschil tussen Critical Patch Updates en Patch Set Updates Releases van Java CPU en PSU uitgelegd.

De demo's, voorbeelden en documentatiebundels voor 8u77 worden niet beïnvloed door de beveiligingswaarschuwing voor CVE-2016-0636. De demo's, voorbeelden en documentatiebundels van versie 8u73 blijven dan ook de meest actuele versies tot de release van de kritieke patch-update van april.

Bugfixes

Deze release bevat fixes voor beveiligingsproblemen. Zie Oracle Java SE Critical Patch Update Advisory voor meer informatie.

» Opmerkingen bij release 8u77

Java 8 Update 73 (8u73)

Hoogtepunten van release

IANA Data 2015g
JDK 8u71 bevat IANA-tijdzonegegevens, versie 2015g. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.

Vervaldatum van Java

De vervaldatum voor 8u73 is 19 april 2016. Java verloopt wanneer een nieuwe release met oplossingen voor beveiligingsproblemen beschikbaar komt. Voor systemen die de Oracle servers niet kunnen bereiken, verloopt deze JRE (versie 8u73) door een secundair mechanisme op 19 mei 2016. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), zal Java aanvullende waarschuwingen en herinneringen aan gebruikers sturen om een update naar de nieuwere versie uit te voeren.

Opmerkingen

Oracle raadt Java-gebruikers die betreffende versies hebben gedownload en die van plan zijn nieuwe installaties met deze gedownloade versies uit te voeren, ten zeerste aan deze oude downloads te negeren. Java-gebruikers die de kritieke patchupdateversies van Java SE 6, 7, of 8 van januari 2016 hebben geïnstalleerd, hoeven geen actie te ondernemen. Java-gebruikers die de kritieke patchupdateversies van Java SE 6, 7, of 8 van januari 2016 niet hebben geïnstalleerd, moeten upgraden naar de Java-releases SE 6, 7, of 8 vanuit de beveiligingswaarschuwing voor CVE-2016-0603.

De demo's, voorbeelden en documentatiebundels voor 8u73 worden niet beïnvloed door de beveiligingswaarschuwing voor CVE-2016-0603. De demo's, voorbeelden en documentatiebundels van versie 8u71 blijven dan ook de meest actuele versies tot de release van de kritieke patch-update van april.

Bugfixes

Deze release bevat fixes voor beveiligingsproblemen. Zie Oracle Java SE Critical Patch Update Advisory voor meer informatie. 8u73 bevat niet de PSU-builds die in 8u72 te vinden waren. Klanten die behoefte hebben aan de extra bugfixes die in 8u72 waren opgenomen, moeten hun versie bijwerken naar 8u74 in plaats van naar 8u73.

» Opmerkingen bij release 8u73

Java 8 Update 71 (8u71)

Hoogtepunten van release

IANA Data 2015g
JDK 8u71 bevat IANA-tijdzonegegevens, versie 2015g. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Bugfix: wanneer jps door de hoofdgebruiker wordt uitgevoerd, worden niet alle gegevens getoond.
Na de fix van JDK-8050807 (hersteld in 8u31, 7u75 en 6u91), werden, wanneer jps door de hoofdgebruiker werd uitgevoerd, op sommige systemen niet alle gegevens getoond over door andere gebruikers gestarte Java-processen. Dit is hersteld. Zie voor meer informatie: JDK-8075773.
Bugfix: installatieprogramma's leken vastgelopen in ESC-configuraties
Het gebruik van Internet Explorer Enhance Security Configuration (ESC) onder Windows Server 2008 R2 gaf mogelijk problemen bij het installeren van Java in interactieve modus. Dit probleem is verholpen in release 8u71. Installatieprogramma's die worden uitgevoerd in interactieve modus zullen niet meer vastgelopen lijken in ESC-configuraties. Zie voor meer informatie: JDK-8140197.
Bugfix: probleem met PBE-algoritmen die AES Crypto gebruiken, is gecorrigeerd.
Een fout is gecorrigeerd voor PBE met 256-bits AES-ciphers. De afgeleide sleutel mag verschillen en hoeft niet gelijk te zijn aan sleutels die eerder zijn afgeleid van hetzelfde wachtwoord. JDK-8138589 (niet openbaar)
Bugfix: standaardlimiet toegevoegd voor maximumentiteitgrootte van XML.
Een standaardlimiet voor maximumentiteitgrootte is toegevoegd. Zie voor meer informatie over de verwerkingslimieten van XML The Java Tutorials, Processing Limits (De Java-zelfstudies, Verwerkingslimieten). JDK-8133962 (niet openbaar)
Bugfix: Documentatie probleem met Enterprise MSI-schakeloptie 'REMOVEOLDERJRES' gecorrigeerd.
De Enterprise MSI documentatie geeft configuratieopties weer. De optie 'REMOVEOLDERJRES' voor het verwijderen van oudere versies van JRE, ontbrak. Deze optie is toegevoegd met de beschrijving:
indien ingesteld op 1, worden oudere releases van JRE die zijn geïnstalleerd op het systeem, verwijderd.
Standaard: bij 0 worden geen oudere versies van JRE verwijderd.
JDK-8081237 (niet openbaar)

Vervaldatum van Java

De vervaldatum voor 8u71 is 19 april 2016. Java verloopt wanneer een nieuwe release met oplossingen voor beveiligingsproblemen beschikbaar komt. Voor systemen die de Oracle Servers niet kunnen bereiken, verloopt deze JRE (versie 8u71) op 19 mei 2016. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), zal Java aanvullende waarschuwingen en herinneringen aan gebruikers sturen om een update naar de nieuwere versie uit te voeren.

Bugfixes

Deze release bevat fixes voor beveiligingsproblemen. Zie Oracle Java SE Critical Patch Update Advisory voor meer informatie.

Zie de pagina JDK 8u71 Bug Fixes voor een lijst met bugfixes in deze release.

» Opmerkingen bij release 8u71

Java 8 Update 66 (8u66)

Hoogtepunten van release

8u66 build 18 lost een probleem op met Firefox.

Bugfix: _releaseObject aangeroepen vanuit onjuiste thread
Door een recente wijziging in Firefox wordt de _releaseObject-aanroep gedaan vanuit een andere thread dan de hoofdthread. Dit kan een 'race condition' veroorzaken, wat tot een onverwachte browsercrash kan leiden. Dit is opgelost in build 18 of 8u66. Zie Bugs@Mozilla 1221448 voor meer informatie. Zie voor meer informatie: JDK-8133523.

Java-plug-in werkt niet in Firefox na installatie van Java.

Firefox 42 kan vastlopen bij het uitvoeren van de Java-plug-in. Opties voor een tijdelijke oplossing worden weergegeven bij de Veelgestelde vragen. Zie JDK-8142908 (niet openbaar).

Vervaldatum van Java

De vervaldatum voor 8u66 is 19 januari 2016. Java verloopt wanneer een nieuwe release met oplossingen voor beveiligingsproblemen beschikbaar komt. Voor systemen die de Oracle servers niet kunnen bereiken, verloopt deze JRE (versie 8u66) door een secundair mechanisme op 19 februari 2016. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), zal Java aanvullende waarschuwingen en herinneringen aan gebruikers sturen om een update naar de nieuwere versie uit te voeren.

Bugfixes

Deze release bevat fixes voor beveiligingsproblemen. Zie Oracle Java SE Critical Patch Update Advisory voor meer informatie.

Zie de pagina JDK 8u66 Bug Fixes voor een lijst met bugfixes in deze release.

» Opmerkingen bij release 8u66

Java 8 Update 65 (8u65)

Hoogtepunten van release

IANA Data 2015f
JDK 8u65 bevat IANA-tijdzonegegevens, versie 2015f. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Ondersteuning voor ISO 4217 'Huidige funds codes' (tabel A.2)
Deze verbetering biedt ondersteuning voor ISO 4217 funds codes tabel A.2. Voorheen bood JDK alleen ondersteuning voor de valuta's die staan vermeld in tabel A.1. Zie voor meer informatie: JDK-8074350.
Bugfix: [mac osx] De geïnstalleerde JRE AU-client kan niet worden bijgewerkt tot NEXTVER op Mac 10.11
Er wordt een nieuwe installer geïntroduceerd in release 8u65 voor een update naar de laatste versie voor OS X-gebruikers. De installer is van toepassing op zowel geplande als handmatige updates, evenals op bundels die op java.com en OTN beschikbaar worden gesteld. Gebruikers die last krijgen van compatibiliteitsproblemen met de nieuwe installer, kunnen handmatig de ".pkg"-installer downloaden en installeren. Deze is beschikbaar op My Oracle Support.
Bugfix: Hotspot dient gebruik te maken van PICL-interface om de cacheregelgrootte op SPARC te bepalen
Voor Solaris/SPARC is nu de libpicl-bibliotheek vereist om de grootte van de cacheregels vast te stellen. Indien de bibliotheek niet aanwezig is of de PICL-service niet beschikbaar, wordt door JVM een waarschuwing weergegeven. Optimaliseringen voor de compiler die gebruikmaken van BIS-instructies (Block Initializing Store) worden uitgeschakeld. Zie voor meer informatie: JDK-8056124.
Bugfix: dns_lookup_realm moet standaard false zijn.
De instelling dns_lookup_realm in het bestand krb5.conf van Kerberos is standaard false. Zie voor meer informatie: JDK-8080637.
Bugfix: het vooraf laden van libjsig.dylib veroorzaakt deadlock als signal() wordt aangeroepen
De bibliotheek libjsig moet vooraf door de applicaties worden geladen om het maken van signaalketens te activeren. Indien voorheen op OS X libjsig.dylib vooraf werd geladen, veroorzaakte een aanroep door native code in signal() deadlock. Dit is gecorrigeerd. Zie voor meer informatie: JDK-8072147.
Bugfix: betere groepsdynamica
In OpenJDK SSL/TLS/DTLS-implementatie (SunJSSE-provider) worden standaard veilige Diffie-Hellman-groepen op basis van priemgetallen gebruikt. Gebruikers kunnen Diffie-Hellman-groepen aanpassen via beveiligingseigenschap jdk.tls.server.defaultDHEParameters.
Bugfix: VM loopt vast als klasse opnieuw wordt gedefinieerd met Instrumentation.redefineClasses
JVM kon vastlopen als een klasse opnieuw werd gedefinieerd met Instrumentation.redefineClasses(). Het vastlopen kon worden veroorzaakt door een segmentatiefout in SystemDictionary::resolve_or_null of door een interne fout met het volgende bericht: 'tag komt niet overeen met vermeldingen in tabel met herleidingsfouten'. Dit is hersteld. Zie voor meer informatie: JDK-8076110.

Opmerkingen

Bij uitvoer op OSX 10.11 El Capitan met geactiveerde SIP kunnen bepaalde omgevingsvariabelen die voor debugapplicaties zijn bedoeld, zoals DYLD_LIBRARY_PATH, uit de omgeving worden gestript als Java wordt uitgevoerd vanaf de opdrachtregel of bij dubbelklikken op een JAR. Applicaties dienen niet van deze variabelen afhankelijk te zijn in een productieomgeving. De variabelen zijn slechts bedoeld voor het debuggen tijdens de ontwikkeling.

MD5 mag niet worden gebruikt voor digitale handtekeningen indien collisieresistente is vereist. Ten einde het gebruik van MD5 als digitale handtekening tijdens X.509-certificaatbewerkingen tegen te gaan, wordt MD5 toegevoegd aan de beveiligingseigenschap jdk.certpath.disabledAlgorithms. Voor applicaties die nog steeds gebruikmaken van met MD5 ondertekende certificaten, dient het zwakke certificaat zo snel mogelijk te worden bijgewerkt.

Bekende problemen

[macosx] Problemen met toegankelijkheid van schermen met aanbiedingen voor sponsorsoftware (a11y)
Gebruikers die het toetsenbord gebruiken voor toegang tot gebruikersinterfaces in de Java-installer, hebben geen toegang tot hyperlinks en selectievakjes in schermen met aanbiedingen voor software-uitbreidingen. Als een tijdelijke oplossing voor het instellen van de voorkeuren in verband met de uitbreidingssoftware in de gebruikersinterface, kunnen gebruikers dergelijke aanbiedingen deactiveren in het Java-besturingspaneel of door SPONSORS=0 door te geven via de opdrachtregel. Zie Veelgestelde vragen: Java installeren zonder aanbiedingen van sponsors voor meer informatie. Zie voor meer informatie: JDK-8061886 (niet openbaar).

Vervaldatum van Java

De vervaldatum voor 8u65 is 19 januari 2016. Java verloopt wanneer een nieuwe release met oplossingen voor beveiligingsproblemen beschikbaar komt. Voor systemen die de Oracle servers niet kunnen bereiken, verloopt deze JRE (versie 8u65) door een secundair mechanisme op 19 februari 2016. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), zal Java aanvullende waarschuwingen en herinneringen aan gebruikers sturen om een update naar de nieuwere versie uit te voeren.

Bugfixes

Deze release bevat fixes voor beveiligingsproblemen. Zie Oracle Java SE Critical Patch Update Advisory voor meer informatie.

Zie de pagina JDK 8u65 Bug Fixes voor een lijst met bugfixes in deze release.

» Opmerkingen bij release 8u65

Java 8 Update 60 (8u60)

Hoogtepunten van release

IANA Data 2015e
JDK 8u60 bevat IANA tijdzonegegevens, versie 2015e. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Bugfix: dns_lookup_realm moet standaard false zijn.
De instelling dns_lookup_realm in het bestand krb5.conf van Kerberos is standaard false. Zie voor meer informatie: 8080637.
Bugfix: RC4-cipher-suites deactiveren
TLS-cipher-suites op basis van RC4 (bijvoorbeeld TLS_RSA_WITH_RC4_128_SHA) worden nu als aangetast beschouwd en mogen niet meer worden gebruikt (zie RFC 7465). Daarom zijn TLS-cipher-suites op basis van RC4 standaard gedeactiveerd in de implementatie van Oracle JSSE doordat "RC4" is toegevoegd aan de beveiligingseigenschap "jdk.tls.disabledAlgorithms" en doordat de suites zijn verwijderd uit de lijst met standaard ingeschakelde cipher-suites. Deze cipher-suites kunnen opnieuw worden geactiveerd door "RC4" te verwijderen uit de beveiligingseigenschap "jdk.tls.disabledAlgorithms" in het bestand java.security of door Security.setProperty() dynamisch aan te roepen. De suites kunnen ook met de methoden SSLSocket/SSLEngine.setEnabledCipherSuites() opnieuw worden toegevoegd aan de lijst met geactiveerde cipher-suites. U kunt ook de opdrachtregeloptie -Djava.security.properties gebruiken om de beveiligingseigenschap jdk.tls.disabledAlgorithms te overschrijven. Bijvoorbeeld: bij
java -Djava.security.properties=my.java.security...
is my.java.security een bestand dat de eigenschap bevat zonder RC4:
jdk.tls.disabledAlgorithms=SSLv3
Zelfs als deze optie wordt ingesteld via de opdrachtregel, moeten de op RC4 gebaseerde cipher-suites opnieuw worden toegevoegd aan de lijst met geactiveerde cipher-suites met de methoden SSLSocket/SSLEngine.setEnabledCipherSuites(). Zie voor meer informatie: 8076221.
Bugfix: ondersteuning van keystoretypedetectie voor JKS- en PKCS12-keystores
Modus keystorecompatibiliteit: ten behoeve van de interoperabiliteit ondersteunt het Java-keystoretype JKS nu standaard de modus voor keystorecompatibiliteit. Met deze modus kunnen JKS-keystores gebruikmaken van de bestandsindelingen JKS en PKCS12. Als u de modus voor keystorecompatibiliteit wilt uitschakelen, stelt u de beveiligingseigenschap keystore.type.compat in op de stringwaarde false. Zie voor meer informatie: 8062552.
Bugfix: onveilige methoden voor volgen in release JDK 8u afkeuren
De methoden monitorEnter monitorExit en tryMonitorEnter in sun.misc.Unsafe zijn in JDK 8u60 gemarkeerd als afgekeurd en zullen in een komende release worden verwijderd. Deze methoden worden binnen de JDK zelf niet gebruikt en zelden buiten de JDK. Zie voor meer informatie: 8069302.
Bugfix: vastgelegde JFR-gegevens met SA uit het kernbestand extraheren
DumpJFR is een hulpprogramma op basis van Serviceability Agent waarmee gegevens van Java Flight Recorder (JFR) uit de kernbestanden en live Hotspot-processen kunnen worden geëxtraheerd. DumpJFR kan in een van de volgende methoden worden gebruikt:
- DumpJFR toevoegen aan een live proces:
  
  The embedded asset does not exist:
  Asset Type: jWidget_C
  Asset Id: 1371164883097
  PAGENAME: JCOM/jWidget_C/Raw_HTML/Display
- DumpJFR toevoegen aan een kernbestand:
  
  The embedded asset does not exist:
  Asset Type: jWidget_C
  Asset Id: 1371164883117
  PAGENAME: JCOM/jWidget_C/Raw_HTML/Display
Het hulpprogramma DumpJFR dumpt de JFR-gegevens in een bestand met de naam recording.jfr in de huidige werkmap. Zie voor meer informatie: 8065301 (niet openbaar).
Bugfix: lokale variabelen met de naam 'enum' leiden tot schijnbare compilercrashes.
De javac-parser ontleedt lokale variabelen met de naam 'enum' onjuist. Dit leidt tot schijnbare fouten wanneer een programma waarin zulke lokale variabelen voorkomen, wordt gecompileerd met een 'source'-vlag die overeenkomt met een release waarin de enum-constructie niet beschikbaar is (bijvoorbeeld '-source 1.4'). Zie voor meer informatie: 8069181.

Java Development Kit for ARM release 8u60

Deze release bevat Java Development Kit for ARM release 8u60 (JDK 8u60 for ARM). Zie voor ondersteuningsgegevens voor ARM-apparaten de pagina JDK for ARM-downloads. Zie de pagina Installation Instructions (Installatie-instructies) voor systeemvereisten, installatie-instructies en tips voor het oplossen van problemen.

Beperking: de ondersteuning voor Native Memory Tracking is beperkt in JDK for ARM. De Java-opdrachtregeloptie XX:NativeMemoryTracking=detail wordt niet ondersteund voor ARM-doelen (gebruikers krijgen een foutbericht te zien). Gebruik in plaats daarvan de volgende optie:
XX:NativeMemoryTracking=summary

Documentatie-updates wegens verbeteringen van Nashorn

JDK 8u60 bevat nieuwe verbeteringen in Nashorn. De wijzigingen in de volgende documentatie moeten daarom samen met de huidige Nashorn documentatie worden gelezen:

Toevoeging: in de vorige sectie hebben we vermeld dat elk JavaScript-object dat in Java-API's wordt toegepast, de interface java.util.Map implementeert. Dit geldt zelfs voor JavaScript-arrays. Dit gedrag is echter vaak niet wenselijk of wordt niet verwacht wanneer in de Java-code objecten worden verwacht die met JSON zijn ontleed. Wanneer in Java-bibliotheken objecten worden gemanipuleerd die met JSON zijn ontleed, worden er gewoonlijk arrays verwacht om de interface java.util.List weer te geven. Als u JavaScript-objecten zo wilt gebruiken dat arrays worden weergegeven als lijsten in plaats van toewijzingen, kunt u de functie Java.asJSONCompatible(obj) gebruiken, waarbij obj het startpunt is van de boomstructuur van het JSON-object.
Correctie: de waarschuwing die aan het eind van de sectie Gegevenstypen toewijzen wordt gegeven, is niet meer van toepassing. Nashorn zorgt ervoor dat interne JavaScript-strings naar java.lang.String worden geconverteerd wanneer ze extern worden gebruikt.
Correctie: de bewering in de sectie Gegevenstypen toewijzen die begint met "Arrays moeten bijvoorbeeld expliciet worden geconverteerd,..." is niet juist. Arrays worden automatisch geconverteerd naar Java-arraytypen, zoals java.util.List java.util.Collection java.util.Queue, java.util.Deque enzovoort.

Wijzigingen in implementatieregelset v1.2

JDK 8u60 implementeert implementatieregelset (DRS) 1.2, die de volgende wijzigingen bevat:

Element checksum toevoegen als subelement van id, waardoor niet-ondertekende jars kunnen worden geïdentificeerd door de controletelling SHA-256 van de niet-gecomprimeerde vorm van een jar:
- Het element checksum komt alleen overeen met niet-ondertekende jars en de gegeven hash wordt alleen vergeleken met de niet-gecomprimeerde vorm van de jar.
- Het element checksum heeft (net als het element certificate) twee argumenten: hash en algorithm maar in tegenstelling tot bij het element certificate is "SHA-256" de enige ondersteunde waarde voor algorithm. Elke andere opgegeven waarde wordt genegeerd.
Toestaan dat het element message wordt toegepast op alle regeltypen, terwijl het eerder alleen van toepassing was op een blokregel:
- In een uitvoeringsregel zorgt een berichtsubelement ervoor dat er een dialoogvenster met een bericht wordt weergegeven, terwijl het standaardgedrag zonder een uitvoeringsregel is dat er een dialoogvenster Certificaat of Niet-ondertekend wordt weergegeven. Het bericht wordt in het berichtvenster weergegeven.
- In een standaardregel wordt het bericht alleen weergegeven als de standaardactie Blokkeren is. In dat geval wordt het bericht opgenomen in het dialoogvenster Blokkeren.
customer-blokken invoegen in de Java-console, traceerbestanden en records van Java Usage Tracker.
- In versies eerder dan DRS 1.2 konden customer-elementen (zonder subelementen) worden opgenomen in het bestand ruleset.xml. Dit element en alle subelementen ervan worden genegeerd. In DRS 1.2 worden de elementen nog steeds functioneel genegeerd. Echter:
  - Wanneer het bestand ruleset.xml wordt ontleed, worden alle customer-blokken ingevoegd in de Java-console en het implementatietraceerbestand (als de console en traceren zijn ingeschakeld).
  - Wanneer er een regel wordt gebruikt, worden alle customer-records in die regel toegevoegd aan het JUT-record (Java Usage Tracker), als JUT tenminste is ingeschakeld.

Als gevolg van bovenstaande wijzigingen is de DTD voor DRS 1.2 als volgt:
The embedded asset does not exist:
Asset Type: jWidget_C
Asset Id: 1385352043373
PAGENAME: JCOM/jWidget_C/Raw_HTML/Display

Vervaldatum van Java

De vervaldatum voor 8u60 is 20 oktober 2015. Java verloopt wanneer een nieuwe release met oplossingen voor beveiligingsproblemen beschikbaar komt. Voor systemen die de Oracle servers niet kunnen bereiken, verloopt deze JRE (versie 8u60) door een secundair mechanisme op 20 november 2015. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), zal Java aanvullende waarschuwingen en herinneringen aan gebruikers sturen om een update naar de nieuwere versie uit te voeren.

Bugfixes

Zie de pagina JDK 8u60 Bug Fixes voor een lijst met bugfixes in deze release.

» Opmerkingen bij release 8u60

Java 8 Update 51 (8u51)

Hoogtepunten van release

IANA Data 2015d
JDK 8u51 bevat IANA tijdzonegegevens, versie 2015d. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Bugfix: nieuwe Comodo startpunten toevoegen aan startcertificeringsinstanties
Er zijn vier nieuwe startcertificaten voor Comodo toegevoegd:
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
Zie JDK-8077997 (niet openbaar).
Bugfix: nieuwe GlobalSign startpunten toevoegen aan startcertificeringsinstanties
Er zijn twee startcertificaten voor GlobalSign toegevoegd:
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
Zie JDK-8077995 (niet openbaar).
Bugfix: Actalis toevoegen aan startcertificeringsinstanties
Er is één nieuw startcertificaat toegevoegd:
Actalis Authentication Root CA alias: actalisauthenticationrootca DN: CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT
Zie voor meer informatie: JDK-8077903 (niet openbaar).
Bugfix: nieuw Entrust ECC startpunt toevoegen
Er is één nieuw startcertificaat toegevoegd:
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
Zie voor meer informatie: JDK-8073286 (niet openbaar).
Bugfix: oude policystartpunten voor Valicert klasse 1 en 2 verwijderen
Er zijn twee startcertificaten met 1024-bits sleutels verwijderd:
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
Zie JDK-8077886 (niet openbaar).
Bugfix: oude Thawte startpunten verwijderen
Er zijn twee startcertificaten met 1024-bits sleutels verwijderd:
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
Zie JDK-8074423 (niet openbaar).
Bugfix: meer oude Verisign, Equifax en Thawte startpunten verwijderen
Er zijn vijf startcertificaten met 1024-bits sleutels verwijderd:
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
Zie JDK-8076202 (niet openbaar).
Bugfix: TrustCenter certificeringsinstantiestartpunten uit cacerts verwijderen
Er zijn drie startcertificaten verwijderd:
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
Zie JDK-8072958 (niet openbaar).
Bugfix: RC4 in SunJSSE provider afkeuren
RC4 wordt nu beschouwd als een zwak cipher. Servers mogen RC4 niet selecteren, tenzij er geen sterkere kandidaat in de door de client aangevraagde cipher-suites is. Er is een nieuwe beveiligingseigenschap jdk.tls.legacyAlgorithms toegevoegd om de verouderde algoritmen in de Oracle JSSE implementatie te definiëren. Aan RC4 gerelateerde algoritmen worden toegevoegd aan de lijst met verouderde algoritmen. Zie JDK-8074006 (niet openbaar).
Bugfix: RC4-cipher-suites verbieden
RC4 wordt nu beschouwd als een aangetast cipher. RC4-cipher-suites zijn verwijderd uit de standaardlijst met actieve cipher-suites op de client en de server in de Oracle JSSE implementatie. Deze cipher-suites kunnen nog steeds worden geactiveerd via de methoden SSLEngine.setEnabledCipherSuites() en SSLSocket.setEnabledCipherSuites(). Zie JDK-8077109 (niet openbaar).
Bugfix: verbeterde certificeringscontrole
Met deze fix wordt bij JSSE-eindpuntidentificatie standaard geen reverse name lookup uitgevoerd voor IP-adressen in JDK. Als een applicatie reverse name lookup moet uitvoeren voor ruwe IP-adressen in SSL/TLS-verbindingen en er een compatibiliteitsprobleem met de eindpuntidentificatie optreedt, kan de systeemeigenschap "jdk.tls.trustNameService" worden gebruikt om reverse name lookup in te schakelen. Als de naamservice niet betrouwbaar is, kan het inschakelen van reverse name lookup ertoe leiden dat uw systeem kwetsbaar wordt voor MITM-aanvallen. Zie JDK-8067695 (niet openbaar).

Vervaldatum van Java

De vervaldatum voor 8u51 is 20 oktober 2015. Java verloopt wanneer een nieuwe release met oplossingen voor beveiligingsproblemen beschikbaar komt. Voor systemen die de Oracle Servers niet kunnen bereiken, verloopt deze JRE (versie 8u51) door een secundair mechanisme op 20 november 2015. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), zal Java aanvullende waarschuwingen en herinneringen aan gebruikers sturen om een update naar de nieuwere versie uit te voeren.

Bugfixes

Deze release bevat fixes voor beveiligingsproblemen. Zie Oracle Java SE Critical Patch Update Advisory voor meer informatie.

Zie de pagina JDK 8u51 Bug Fixes voor een lijst met bugfixes in deze release.

» Opmerkingen bij release 8u51

Java 8 Update 45 (8u45)

Hoogtepunten van release

IANA Data 2015a
JDK 8u45 bevat IANA tijdzonegegevens, versie 2015a. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Bugfix: afhandeling van JAR-bestanden verbeteren Bij het maken of uitpakken van een ZIP- of JAR-bestand met het hulpprogramma jar is het vanaf JDK 8u45 niet langer toegestaan om bij de invoer van het pad van het zipbestand een voorafgaande schuine streep '/' en '..' (punt-punt) te gebruiken. Gebruik de nieuwe opdrachtregeloptie "-P" wanneer het nodig is om het pad met punt-punt en/of het absolute pad te behouden. Zie voor meer informatie: 8064601 (niet openbaar).
Bugfix: uitvoering van een jnlp-applicatie met geneste 'resource'-sectie mislukt met een NPE bij het laden in jre8u40. Een jnlp-applicatie met geneste -tags binnen de tag <java> of kan een NPE veroorzaken. Dit probleem is nu opgelost. De tag mag alleen worden gebruikt als de tag <java> ook daadwerkelijk wordt gebruikt. Zie voor meer informatie: 8072631 (niet openbaar).

Vervaldatum van Java

De vervaldatum voor 8u45 is 14 juli 2015. Java verloopt wanneer een nieuwe release met oplossingen voor beveiligingsproblemen beschikbaar komt. Voor systemen die de Oracle Servers niet kunnen bereiken, verloopt deze JRE (versie 8u45) door een secundair mechanisme op 14 augustus 2015. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), zal Java aanvullende waarschuwingen en herinneringen aan gebruikers sturen om een update naar de nieuwere versie uit te voeren.

Bugfixes

Deze release bevat fixes voor beveiligingsproblemen. Zie Oracle Java SE Critical Patch Update Advisory voor meer informatie.

Zie de pagina JDK 8u45 Bug Fixes voor een lijst met bugfixes in deze release.

» Opmerkingen bij release 8u45

Java 8 Update 40 (8u40)

Hoogtepunten van release

IANA Data 2014j
JDK 8u40 bevat IANA tijdzonegegevens, versie 2014j. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Bugfix: standaard interfacemethoden en statische interfacemethoden in JDI, JDWP en JDB. Sinds JDK 8 is het mogelijk rechtstreeks uitvoerbare statische methoden en standaardmethoden te gebruiken in interfaces. Deze methoden kunnen niet worden uitgevoerd via JDWP of JDI, en kunnen daarom niet goed worden gedebugd. Zie voor meer informatie JDK 8 Compatibility Guide. Zie voor meer informatie: 8042123.
Bugfix: Java Access Bridge kan worden geactiveerd vanuit het besturingspaneel voor 32-bits JRE's. Voorheen werd het selectievakje 'Enable Java Access Bridge' uit het Java-besturingspaneel verwijderd bij het verwijderen van de 64-bits JRE, zelfs als de 32-bits JRE nog op het systeem aanwezig was. Vanaf JDK release 8u40 blijft het selectievakje 'Enable Java Access Bridge' behouden, onder Control Panel \Ease of Access \Ease of Access Center \Use the computer without a display als een 32-bits JRE aanwezig is. Een gebruiker kan Java Access Bridge dus activeren via het besturingspaneel. Zie 8030124 voor meer informatie.
Bugfix: JavaFX Media Stack bijwerken op Mac OS X. Aan JavaFX media is een platform voor op AVFoundation gebaseerde spelers toegevoegd. Het oude op QTKit gebaseerde platform kan nu worden verwijderd, voor compatibiliteit met Mac App Store. Zie voor meer informatie: 8043697 (niet openbaar)
Bugfix: Ontbrekende DOM-API's In JDK release 8u40 zijn de DOM-API's van de oude plug-in per ongeluk verwijderd. Als een applet com.sun.java.browser.dom.DOMService nodig heeft om met de browser te communiceren, moeten gebruikers mogelijk hun applet zo bijwerken dat netscape.javascript.JSObject wordt gebruikt, of moeten zij JDK 8 Update 31 blijven gebruiken. Dit probleem is verholpen in build 26 en er zijn nieuwe installatieprogramma's voor 8u40 gepubliceerd. Als u last hebt van dit probleem, downloadt u de bijgewerkte installatieprogramma's voor JDK 8u40 en voert u ze uit. Zie voor meer informatie: 8074564.
Bugfix: Mac 10.10: applicaties die worden uitgevoerd met het welkomstscherm, hebben problemen met de focus. Het toetsenbord kan de focus niet krijgen van zelfstandige of via webstart gestarte applicaties die gebruikmaken van het welkomstscherm. Tijdelijke oplossing: start javaws met de optie -Xnosplash. Dit probleem is verholpen in build 27 en er is een nieuw installatieprogramma voor 8u40 gepubliceerd. Als u last hebt van dit probleem, downloadt u het bijgewerkte installatieprogramma voor JDK 8u40 en voert u het uit. Zie voor meer informatie: 8074668.
Verbeteringen voor Java-verpakkingsprogramma
JDK-release 8u40 bevat de volgende verbeteringen voor het Java-verpakkingsprogramma:
- Opdrachtregelargumenten kunnen worden doorgegeven aan onafhankelijke applicaties. Bij het maken van het pakket worden standaardargumenten gedefinieerd. Deze kunnen door de gebruiker worden overschreven bij het starten van de applicatie.
- Bij het installeren van een onafhankelijke applicatie is het mogelijk om bestandskoppelingen in te stellen zodat de applicatie automatisch door het besturingssysteem wordt uitgevoerd voor geregistreerde bestandsextensies of MIME-typen.
- De API UserJvmOptionsService is beschikbaar voor het wijzigen van JVM-opties in onafhankelijke applicaties. De nieuwe instellingen worden van kracht zodra de applicatie opnieuw is gestart.
- Er worden meerdere ingangspunten voor onafhankelijke applicaties ondersteund, zodat een suite met verschillende producten kan worden gebundeld in één applicatiepakket.
Verouderde API's
De mechanismen endorsed-standards override en extension zijn verouderd en worden in een volgende release mogelijk verwijderd. Er zijn geen runtimewijzigingen. Het is raadzaam bestaande applicaties met de mechanismen 'endorsed-standards override' en 'extension' te migreren naar applicaties zonder deze mechanismen. Voor het opsporen van alle bestaande voorvallen van deze mechanismen kunt u de opdrachtregeloptie -XX:+CheckEndorsedAndExtDirs gebruiken. Deze optie werkt echter niet in de volgende gevallen:
- De systeemeigenschap -Djava.endorsed.dirs of -Djava.ext.dirs is zo ingesteld, dat de standaardlocatie wordt gewijzigd.
- De directory ${java.home}/lib/endorsed bestaat.
- ${java.home}/lib/ext bevat een of meer JAR-bestanden naast de JAR-bestanden die door JDK worden verstuurd.
- De directory van een platformspecifieke, systeembrede uitbreiding bevat een of meer JAR-bestanden.
De opdrachtregeloptie -XX:+CheckEndorsedAndExtDirs wordt ondersteund in JDK-release 8u40 en hoger.
Verschillende pagina's voor hulpprogramma JJS
De Japanse versie van de helppagina voor jjs is anders dan de Engelse versie. Sommige niet-ondersteunde opties zijn verwijderd uit de Engelse versie van de pagina voor het hulpprogramma jjs. De Japanse versie van het document wordt later bijgewerkt. Zie voor meer informatie: 8062100 (niet openbaar). Zie Tools Enhancements in JDK 8 voor overige wijzigingen in de pagina voor het hulpprogramma jjs.
Wijziging in standaardwaarden voor G1HeapWastePercent en G1MixedGCLiveThresholdPercent
De standaardwaarde voor G1HeapWastePercent is gewijzigd van 10 in 5 om de behoefte aan volledige GC's (garbage collectors) te verminderen. Om dezelfde reden is de standaardwaarde voor G1MixedGCLiveThresholdPercent gewijzigd van 65 in 85.
Nieuwe filterinterface voor toegang tot Java-klassen
Met de interface jdk.nashorn.api.scripting.ClassFilter kunt u de toegang tot specifieke Java-klassen beperken via scripts die worden uitgevoerd door een Nashorn-scriptengine. Zie Restricting Script Access to Specified Java Classes in de Nashorn User's Guide en 8043717 (niet openbaar) voor meer informatie.
Problemen met JCE-providers van derden
Met de fix voor JDK-8023069 (in JDK 8u20) worden de SunJSSE-provider, de SunJCE-provider en sommige interne interfaces bijgewerkt. Sommige JCE-providers van derden (zoals RSA JSAFE) maken gebruik van sun.* internal-interfaces, en werken daarom niet met de bijgewerkte SunJSSE-provider. Dergelijke providers moeten worden bijgewerkt om te kunnen functioneren met de bijgewerkte SunJSSE-provider. Neem contact op met uw JCE-leverancier voor een update als dit bij u het geval is. Zie voor meer informatie: 8058731.
Opnieuw geactiveerde coderingstypen in Solaris Crypto Framework
Voor gebruikers van Solaris 10 is een wijziging aangebracht om bewerkingen met MD5, SHA1 en SHA2 via het Solaris Crypto Framework weer mogelijk te maken. Als u de foutmelding CloneNotSupportedException of PKCS11-foutmelding CKR_SAVED_STATE_INVALID krijgt bij JDK 8u40, moet u controleren of u beschikt over de hieronder vermelde patches, of een meer recente versie daarvan, en deze zo nodig toepassen:
- 150531-02 op sparc
- 150636-01 op x86
Troubleshooting Guide-updates voor NMT
NMT (Native Memory Tracking) is een Java Hotspot VM-functie waarmee het interne-geheugengebruik voor een HotSpot JVM wordt bijgehouden. Native Memory Tracking kan worden gebruikt voor het volgen van interne VM-geheugentoewijzingen en VM-geheugenlekdiagnose. De pagina met verbeteringen voor VM is bijgewerkt met NMT-functies. Zie voor meer informatie: Java Virtual Machine Enhancements in Java SE 8. De Troubleshooting Guide is bijgewerkt met NMT-functies. Zie voor meer informatie: Native Memory Tracking.
Functie voor opstarten van verschillende JRE's verwijderd
De functie voor selectie van de JRE-versie bij het opstarten of de functie voor het opstarten van verschillende JRE's is verwijderd uit JDK 8u40. Applicaties die deze functie gebruiken om te vereisen dat een specifieke Java versie is geïmplementeerd, moeten overschakelen naar alternatieve implementatieoplossingen, zoals Java WebStart.
JavaFX Enhancements
Te beginnen met de 8u40-release van de JDK zijn de JavaFX besturingselementen uitgebreid met hulptechnologie, wat betekent dat JavaFX besturingselementen nu toegankelijk zijn. Bovendien wordt er een openbare API geboden waarmee ontwikkelaars hun eigen toegankelijke besturingselementen kunnen schrijven. Ondersteuning voor toegankelijkheid wordt geboden op Windows en Mac OS X platforms en houdt het volgende in:
- Ondersteuning voor het lezen van JavaFX besturingselementen door een schermlezer.
- JavaFX besturingselementen kunnen worden doorlopen met behulp van het toetsenbord.
- Ondersteuning voor een speciale hoog-contrastmodus die besturingselementen beter zichtbaar maakt voor gebruikers.
Zie voor meer informatie: 8043344 (niet openbaar).

De JDK 8u40-release bevat nieuwe JavaFX-interfacebesturingselementen: een spinnerbesturingselement, ondersteuning voor opgemaakte tekst en een standaardset waarschuwingsvensters.
- Spinnerbesturingselement: een spinner is een tekstveld met één regel, waarin de gebruiker een getal of een objectwaarde kan selecteren uit een geordende reeks. Zie de klasse javafx.scene.control.Spinner voor meer informatie.
- Opgemaakte tekst: de nieuwe TextFormatter-klasse biedt tekstopmaakmogelijkheden voor subklassen van TextInputControl (bijvoorbeeld TextField en TextArea). Zie de klasse javafx.scene.control.TextFormatter voor meer informatie.
- Dialoogvensters: de Dialog-klasse maakt het applicaties mogelijk aangepaste dialoogvensters te maken. Verder wordt er ook een Alert-klasse geboden, die Dialog uitbreidt en ondersteuning biedt voor een aantal vooraf gebouwde typen dialoogvensters die gemakkelijk aan gebruikers kunnen worden getoond om een reactie te vragen. Zie de klassen javafx.scene.control.Dialog javafx.scene.control.Alert javafx.scene.control.TextInputDialog javafx.scene.control.ChoiceDialog voor meer informatie.
Zie voor meer informatie: 8043350 (niet openbaar).

Commerciële functies

Application Class Data Sharing (AppCDS)
Application Class Data Sharing (AppCDS) vormt een uitbreiding op CDS waarmee u klassen uit de directory's van standaarduitbreidingen en het applicatieklassenpad in het gedeelde archief kunt plaatsen. Dit is een experimentele functie die niet is gelicentieerd voor commercieel gebruik. Zie voor meer informatie de optie -XX:+UseAppCDS op de pagina voor het Java-startprogramma.
Cooperative Memory Management
Vanaf JDK 8u40 is het begrip 'memory pressure' (geheugendruk) toegevoegd aan de JDK. Geheugendruk is een eigenschap die staat voor het totale geheugengebruik (RAM) in het systeem. Hoe hoger de geheugendruk, hoe eerder het systeemgeheugen onvoldoende wordt. Dit is een experimentele functie die niet is gelicentieerd voor commercieel gebruik. Als reactie op toenemende geheugendruk wordt door de JDK geprobeerd het geheugengebruik te verminderen. Dit gebeurt meestal door de Java-heapgrootte te verkleinen. Door de acties van de JDK om het geheugengebruik te verminderen, kunnen de prestaties afnemen. Dit is een bewuste keuze. Het drukniveau wordt door de applicatie bepaald via een JMX-MXBean en uitgedrukt in een schaal van 0 (geen druk) tot 10 (bijna onvoldoende geheugen). Deze functie kan pas worden geactiveerd als jdk.management.cmm.SystemResourcePressureMXBean is geregistreerd. De geheugendruk wordt vervolgens ingesteld met behulp van het attribuut 'MemoryPressure'.
Er is ook een nieuwe opdrachtregelvlag beschikbaar, -XX:MemoryRestriction, waarbij u een van de volgende argumenten kunt opgeven: 'none' (geen), 'low' (laag), 'medium' (normaal) of 'high' (hoog). Hiermee wordt de initiële druk in de JDK ingesteld. Dit werkt ook als de MXBean niet is geregistreerd. Voor Cooperative Memory Management is de GC 'G1' vereist (-XX:+UseG1GC). Deze functie is niet compatibel met de vlag -XX:+ExplicitGCInvokesConcurrent.
Nieuwe commerciële vlaggen
Er zijn nu twee nieuwe VM-opties beschikbaar voor houders van een commerciële licentie:
- -XX:+ResourceManagement
- -XX:ResourceManagementSampleInterval=waarde (in milliseconden)
Zie de documentatie van het Java-startprogramma voor meer informatie.
Nieuwe documentatie over het MSI-installatieprogramma:
De Microsoft Windows Installer (MSI) Enterprise JRE Installer Guide is beschikbaar. Voor de MSI Enterprise JRE Installer is een commerciële licentie voor gebruik in een productieomgeving vereist. Klik hier voor meer informatie over (het activeren van) commerciële functies.

Vervaldatum van Java

De vervaldatum voor 8u40 is 14 april 2015. Java verloopt wanneer een nieuwe release met oplossingen voor beveiligingsproblemen beschikbaar komt. Voor systemen die de Oracle Servers niet kunnen bereiken, verloopt deze JRE (versie 8u40) door een secundair mechanisme op 14 mei 2015. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), zal Java aanvullende waarschuwingen en herinneringen aan gebruikers sturen om een update naar de nieuwere versie uit te voeren.

Bugfixes

Zie de pagina JDK 8u40 Bug Fixes voor een lijst met bugfixes in deze release.

» Opmerkingen bij release 8u40

Java 8 Update 31 (8u31)

Hoogtepunten van release

IANA Data 2014j
JDK 8u31 bevat IANA tijdzonegegevens, versie 2014j. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
SSLv3 is standaard inactief
Vanaf JDK-release 8u31 is het SSLv3-protocol (Secure Socket Layer) gedeactiveerd en niet standaard beschikbaar. Zie de eigenschap jdk.tls.disabledAlgorithms in het bestand \lib\security\java.security. Als SSLv3 absoluut vereist is, kan het protocol opnieuw worden geactiveerd door 'SSLv3' te verwijderen uit de eigenschap jdk.tls.disabledAlgorithms in het bestand java.security of door deze beveiligingseigenschap dynamisch in te stellen voordat JSSE wordt geïnitialiseerd.
Wijzigingen aan het Java-besturingspaneel
Vanaf JDK-release 8u31 is het SSLv3-protocol verwijderd uit de opties van Java-besturingspaneel Advanced (uitgebreid). Als de gebruiker SSLv3 voor applicaties wil gebruiken, activeert u het als volgt handmatig opnieuw:
- Activeer het SSLv3-protocol op JRE-niveau, zoals beschreven in de vorige sectie.
- Activeer het SSLv3-protocol op implementatieniveau: bewerk het bestand deployment.properties en voeg het volgende toe:
  
  deployment.security.SSLv3=true

Vervaldatum van Java

De vervaldatum voor 8u31 is 14 april 2015. Java verloopt wanneer een nieuwe release met oplossingen voor beveiligingsproblemen beschikbaar komt. Voor systemen die de Oracle Servers niet kunnen bereiken, verloopt deze JRE (versie 8u31) door een secundair mechanisme op 14 april 2015. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), zal Java aanvullende waarschuwingen en herinneringen aan gebruikers sturen om een update naar de nieuwere versie uit te voeren.

Bugfixes

Deze release bevat fixes voor beveiligingsproblemen. Zie Oracle Java SE Critical Patch Update Advisory voor meer informatie.

Zie de pagina JDK 8u31 Bug Fixes voor een lijst met bugfixes in deze release.

» Opmerkingen bij release 8u31

Java 8 Update 25 (8u25)

Hoogtepunten van release

IANA Data 2014c
JDK 8u25 bevat IANA tijdzonegegevens, versie 2014c. Raadpleeg Timezone Data Versions in the JRE Software voor meer informatie.
Bugfix: de voorkeursmodus van RC4 in de lijst met actieve cipher-suites verlagen
Met deze fix wordt de voorkeur van op RC4 gebaseerde cipher-suites in de standaardlijst met actieve cipher-suites van de SunJSSE-provider verlaagd. Zie voor meer informatie: 8043200 (niet openbaar).
Bugfix: JRE 8u20 loopt vast bij het gebruik van Japanse IM in Windows.
De VM loopt vast bij het gebruik van Swing-besturingselementen bij de invoer van bepaalde Japanse of Chinese tekens op een Windows-platform. Dit probleem is nu opgelost. Zie voor meer informatie: 8058858 (niet openbaar).

Instructies voor het deactiveren van SSL v3.0 in Oracle JDK en JRE

Oracle raadt gebruikers en ontwikkelaars aan het SSLv3-protocol te deactiveren.
» Hoe kunnen Java gebruikers controleren of zij niet getroffen zijn door de kwetsbaarheid 'Poodle' via SSL V3.0?

Vervaldatum van Java

De vervaldatum voor 8u25 is 20 januari 2015. Java verloopt wanneer een nieuwe release met oplossingen voor beveiligingsproblemen beschikbaar komt. Voor systemen die de Oracle Servers niet kunnen bereiken, verloopt deze JRE (versie 8u25) door een secundair mechanisme op 20 februari 2015. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), zal Java aanvullende waarschuwingen en herinneringen aan gebruikers sturen om een update naar de nieuwere versie uit te voeren.

Bugfixes

Deze release bevat fixes voor beveiligingsproblemen. Zie Oracle Java SE Critical Patch Update Advisory voor meer informatie.

Zie de pagina JDK 8u25 Bug Fixes voor een lijst met bugfixes in deze release.

» Opmerkingen bij release 8u25

Java 8 Update 20 (8u20)

Hoogtepunten van release

Nieuwe vlaggen toegevoegd aan beheer-API in Java
De vlaggen MinHeapFreeRatio en MaxHeapFreeRatio zijn beheerbaar gemaakt. Dit betekent dat de vlaggen bij runtime kunnen worden gewijzigd met de beheer-API in Java. Ondersteuning voor deze vlaggen is ook toegevoegd aan ParallelGC als onderdeel van de policy van adaptieve grootte.
Wijzigingen in het Java-installatieprogramma
- Er is een nieuwe Microsoft Windows Installer (MSI) Enterprise JRE Installer beschikbaar waarmee gebruikers de JRE in de gehele onderneming kunnen installeren. Zie voor meer informatie de sectie Downloading the Installer in JRE Installation for Microsoft Windows. De MSI Enterprise JRE Installer is alleen beschikbaar als onderdeel van Java SE Advanced of Java SE Suite. Zie voor meer informatie over deze commerciële producten Java SE Advanced en Java SE Suite.
- Het Java-verwijderprogramma is geïntegreerd met het installatieprogramma om de optie te bieden oudere versies van Java van het systeem te verwijderen. Deze wijziging is van toepassing op Windows platforms van 32-bits en 64-bits. Zie Uninstalling the JRE.
Wijzigingen in het Java-besturingspaneel
- Via het tabblad Update in het Java-besturingspaneel kunnen gebruikers nu automatisch 64-bits JRE's (naast 32-bits versies) op hun computer bijwerken.
- Het beveiligingsniveau Medium (Gemiddeld) is verwijderd. Alleen de niveaus High (Hoog) en Very High (Zeer hoog) zijn nu beschikbaar. Applets die niet voldoen aan de laatste beveiligingsregels kunnen nog steeds worden uitgevoerd door de sites waarop ze worden gehost op te nemen in de Exception Site List (lijst met uitgezonderde websites). Dankzij de lijst met uitgezonderde websites hebben gebruikers de optie dezelfde applets toe te staan die zouden zijn toegestaan als de optie Medium (Gemiddeld) was geselecteerd, maar dan per site, waardoor het risico van het gebruik van meer tolerante instellingen wordt geminimaliseerd.
Java-compiler bijgewerkt
De javac-compiler is zodanig bijgewerkt dat de analyse van de definitieve toewijzing voor de toegang tot lege definitieve velden wordt geïmplementeerd met 'this'. Zie voor meer informatie JDK 8 Compatibility Guide.
Wijziging in minimaal vereiste Java-versie voor de Java-plug-in en Java Webstart
De minimaal vereiste Java-versie voor de Java-plug-in en Java Webstart is nu Java 5. Applets die niet kunnen worden uitgevoerd in Java 5 of later moeten worden overgezet naar een latere versie van Java om te kunnen blijven werken. Applets die voor eerdere versies zijn geschreven maar wel in Java 5 of later kunnen worden uitgevoerd, blijven werken.
Wijziging in UsageTracker-uitvoeropmaak
UsageTracker-uitvoeropmaak is zodanig gewijzigd dat er nu aanhalingstekens worden gebruikt, om verwarring in het logbestand te vermijden. Hierdoor moeten mogelijk wijzigingen worden aangebracht in de manier waarop dergelijke informatie wordt gelezen. De functie kan worden ingesteld om op dezelfde manier te werken als in vorige versies, hoewel de nieuwe opmaak wordt aanbevolen. Zie de documentatie bij Java Usage Tracker.
Wijzigingen in Java-verpakkingsprogramma's
- De naam javafxpackager is gewijzigd in javapackager.
- De optie "-B" is toegevoegd aan de javapackager-implementatieopdracht, zodat u argumenten kunt doorgeven aan de bundlers die worden gebruikt om onafhankelijke applicaties te maken. Zie voor meer informatie de documentatie bij javapackager (Windows)/(Unix).
- Het helperparameterargument is toegevoegd aan JavaFX Ant Task Reference. Hierdoor kunt u een argument opgeven (in het element ) voor de bundler waarmee onafhankelijke applicaties worden gemaakt.

Vervaldatum van Java

De vervaldatum voor 8u20 is 14 oktober 2014. Java verloopt wanneer een nieuwe release met oplossingen voor beveiligingsproblemen beschikbaar komt. Voor systemen die de Oracle Servers niet kunnen bereiken, verloopt deze JRE (versie 8u20) door een secundair mechanisme op 14 november 2014. Nadat aan een van de voorwaarden is voldaan (nieuwe release beschikbaar gekomen of vervaldatum bereikt), zal Java aanvullende waarschuwingen en herinneringen aan gebruikers sturen om een update naar de nieuwere versie uit te voeren.

Bugfixes

Zie de pagina JDK 8u20 Bug Fixes voor een lijst met bugfixes in deze release.

» Opmerkingen bij release 8u20

Java 8 Update 11 (8u11)

Deze release bevat fixes voor beveiligingsproblemen. Zie voor meer informatie Oracle Critical Patch Update Advisory.

Zie de pagina JDK 8u11 Bug Fixes voor een lijst met bugfixes in deze release.

» Opmerkingen bij release 8u11

Java 8 Update 5 (8u5)

Deze release bevat fixes voor beveiligingsproblemen. Zie voor meer informatie Oracle Critical Patch Update Advisory.

Zie de pagina JDK 8u5 Bug Fixes voor een lijst met bugfixes in deze release.

» Opmerkingen bij release 8u5

Java 8 Release

» Opmerkingen bij JDK- en JRE 8-release