Java.com

Downloaden Help

Afdrukbare versie

Hoogtepunten Java 8-release


Dit artikel is van toepassing op:
  • 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 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.
  • 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 (niet 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. Daarom zijn DSA-sleutels die kleiner zijn dan 1024 bits standaard gedeactiveerd door "DSA keySize < 1024" toe te voegen aan de beveiligingseigenschap "jdk.certpath.disabledAlgorithms". 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
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" and "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 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 bestand jarsigner 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:
  1. hotspot/jvm/os/processor/cpu_load
  2. 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 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 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 JDK-8154757.

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

    Sonera Class1 CA is verwijderd.
    Het certificaat voor de startcertificeringsinstantie "Sonera Class1 CA" is uit het bestand cacerts verwijderd. Zie 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 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 JDK-6483657 voor meer informatie.
  • 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)

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.

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.

» 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 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)

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
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 JDK-8075773 voor meer informatie.
  • 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 JDK-8140197 voor meer informatie.
  • 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 deze optie is ingesteld op 1, worden oudere releases van JRE die op het systeem zijn geïnstalleerd, 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 is 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 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 JDK-8074350 voor meer informatie.
  • 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 JDK-8056124 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 JDK-8080637 voor meer informatie.
  • 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 JDK-8072147 voor meer informatie.
  • 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 JDK-8076110 voor meer informatie.
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.

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

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

    • DumpJFR toevoegen aan een kernbestand:

      java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.tools.DumpJFR <java> <core>
    Het hulpprogramma DumpJFR dumpt de JFR-gegevens in een bestand met de naam recording.jfr in de huidige werkmap. Zie 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 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:
<!ELEMENT ruleset (rule*)>
<!ATTRIBUTE ruleset href CDATA #IMPLIED>
<!ATTRIBUTE ruleset version CDATA #REQUIRED>

<!ELEMENT rule (id, action)>

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

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

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

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

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 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 een <java>- of -tag kan een NPE veroorzaken. Dit probleem is nu opgelost. De tag mag alleen worden gebruikt als de tag <java> werkelijk wordt gebruikt. Zie 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 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 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:
  • 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 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 afgekeurd
    De functie voor selectie van de JRE-versie bij het opstarten of de functie voor het opstarten van verschillende JRE's, zoals eerder beschreven in de documentatie, wordt afgekeurd in 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 8043344 (niet openbaar).

    de 8u40-release van de JDK bevat nieuwe JavaFX interfacebesturingselementen: een spinnerbesturingselement, ondersteuning voor opgemaakte tekst, en een standaardset met 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 en javafx.scene.control.ChoiceDialog voor meer informatie.
    Zie 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.
  • Documentatie over MSI-installatieprogramma toegevoegd
    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 8043200 (niet openbaar).
  • Bugfix: JRE 8u20 loopt vast bij gebruik van Japanse IM in Windows
    VM loopt vast bij gebruik van Swing besturingselementen bij invoer van sommige Japanse of Chinese tekens op een Windows platform. Dit probleem is nu opgelost. Zie 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 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


Mogelijk bent u ook geïnteresseerd in:




Taal kiezen | Info over Java | Ondersteuning | Ontwikkelaars
Privacy  | Voorwaarden voor gebruik | Handelsmerken | Afwijzing van aansprakelijkheid

Oracle