Software-update: Oracle Java 9.0.4

JavaOracle heeft versie 9.0.4 van Java Standard Edition uitgebracht, zoals gewoonlijk in de smaken Java SE Development Kit (JDK), Java Runtime Environment (JRE) en Server Java Runtime Environment (Server JRE). De downloads zijn beschikbaar voor Windows, Linux, macOS en Solaris. De bijbehorende releasenotes zien er als volgt uit:

Java SE Development Kit 9.0.4 (JDK 9.0.4)

The full version string for this update release is 9.0.4+11 (where "+" means "build"). The version number is 9.0.4.

For the January CPU, two different JDK9 bundles have been released:
  • Oracle JDK 9.0.4 (contains non-public commercial features, deploy, installers, etc.)
  • OpenJDK 9.0.4 (built only from OpenJDK source code)
This page provides release notes for both bundles. Content that only applies to a specific bundle is presented in sections that contain either OpenJDK or Oracle JDK in their titles. Changes that apply to both bundles are presented in sections that do not have OpenJDK or Oracle JDK in their titles.

NOTE: This is the final planned release for JDK 9.
Users of JDK 9 should update to JDK 10 between its release in March 2018 and the next planned Critical Update Release in April 2018.

IANA Data 2017c
JDK 9.0.4 contains IANA time zone data version 2017c. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines
The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 9.0.4 are specified in the following table:
JRE Family Version   JRE Security Baseline
9                    9.0.4+11 
8                    1.8.0_161-b12 
7                    1.7.0_171-b11 
6                    1.6.0_181-b10

JRE Expiration Date for Oracle JDK
The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 9.0.4) will expire with the release of the next critical patch update scheduled for April 17, 2018.
For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 9.0.4) on May 17, 2018. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see JRE Expiration Date.

New Features in OpenJDK 9
  • security-libs/ - Open source the root certificates in Oracle's Java SE Root CA program
    The OpenJDK 9 binary for Linux x64 contains an empty cacerts keystore. This prevents TLS connections from being established because there are no Trusted Root Certificate Authorities installed. As a workaround for OpenJDK 9 binaries, users had to set the System Property to use a different keystore.
    "JEP 319: Root Certificates" addresses this problem by populating the cacerts keystore with a set of root certificates issued by the CAs of Oracle's Java SE Root CA Program. As a prerequisite, each CA must sign the Oracle Contributor Agreement (OCA), or an equivalent agreement, to grant Oracle the right to open-source their certificates.
New Features
  • security-libs/ - Added TLS session hash and extended master secret extension support
    Support has been added for the TLS session hash and extended master secret extension (RFC 7627) in JDK JSSE provider. Note that in general, server certificate change is restricted if endpoint identification is not enabled and the previous handshake is a session-resumption abbreviated initial handshake, unless the identities represented by both certificates can be regarded as the same. However, if the extension is enabled or negotiated, the server certificate changing restriction is not necessary and will be discarded accordingly. In case of compatibility issues, an application may disable negotiation of this extension by setting the System Property jdk.tls.useExtendedMasterSecret to false in the JDK. By setting the System Property jdk.tls.allowLegacyResumption to false, an application can reject abbreviated handshaking when the session hash and extended master secret extension is not negotiated. By setting the System Property jdk.tls.allowLegacyMasterSecret to false, an application can reject connections that do not support the session hash and extended master secret extension.
  • security-libs/ - Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS
    The JDK SunJSSE implementation now supports the TLS FFDHE mechanisms defined in RFC 7919. If a server cannot process the supported_groups TLS extension or the named groups in the extension, applications can either customize the supported group names with jdk.tls.namedGroups, or turn off the FFDHE mechanisms by setting the System Property jsse.enableFFDHEExtension to false.
  • other-libs/corba - Add additional IDL stub type checks to org.omg.CORBA.ORBstring_to_object method
    Applications that either explicitly or implicitly call org.omg.CORBA.ORB.string_to_object, and wish to ensure the integrity of the IDL stub type involved in the ORB::string_to_object call flow, should specify additional IDL stub type checking. This is an "opt in" feature and is not enabled by default.
    To take advantage of the additional type checking, the list of valid IDL interface class names of IDL stub classes is configured by one of the following:
    • Specifying the security property com.sun.CORBA.ORBIorTypeCheckRegistryFilter located in the file conf/security/ in Java SE 9 or in jre/lib/security/ in Java SE 8 and earlier.
    • Specifying the system property com.sun.CORBA.ORBIorTypeCheckRegistryFilter with the list of classes. If the system property is set, its value overrides the corresponding property defined in the configuration.
    If the com.sun.CORBA.ORBIorTypeCheckRegistryFilter property is not set, the type checking is only performed against a set of class names of the IDL interface types corresponding to the built-in IDL stub classes.
  • security-libs/javax.crypto - RSA public key validation
    In 9.0.4, the RSA implementation in the SunRsaSign provider will reject any RSA public key that has an exponent that is not in the valid range as defined by PKCS#1 version 2.2. This change will affect JSSE connections as well as applications built on JCE.
  • security-libs/javax.crypto - Provider default key size is updated
    This change updates the JDK providers to use 2048 bits as the default key size for DSA instead of 1024 bits when applications have not explicitly initialized the and objects with a key size.
    If compatibility issues arise, existing applications can set the system property introduced in JDK-8181048 with the algorithm and its desired default key size.
  • security-libs/javax.crypto - Stricter key generation
    The generateSecret(String) method has been mostly disabled in the javax.crypto.KeyAgreement services of the SUN and SunPKCS11 providers. Invoking this method for these providers will result in a NoSuchAlgorithmException for most algorithm string arguments. The previous behavior of this method can be re-enabled by setting the value of the jdk.crypto.KeyAgreement.legacyKDF system property to true (case insensitive). Re-enabling this method by setting this system property is not recommended.
  • security-libs/ - Disable exportable cipher suites
    To improve the strength of SSL/TLS connections, exportable cipher suites have been disabled in SSL/TLS connections in the JDK by the jdk.tls.disabledAlgorithms Security Property.
  • core-svc/ - JMX Connections need deserialization filters
    New public attributes, RMIConnectorServer.CREDENTIALS_FILTER_PATTERN and RMIConnectorServer.SERIAL_FILTER_PATTERN have been added to With these new attributes, users can specify the deserialization filter pattern strings to be used while making a RMIServer.newClient() remote call and while sending deserializing parameters over RMI to server respectively.
    The user can also provide a filter pattern string to the default agent via As a result, a new attribute is added to
    Existing attribute RMIConnectorServer.CREDENTIAL_TYPES is superseded by RMIConnectorServer.CREDENTIALS_FILTER_PATTERN and has been removed.
Bug Fixes
  • deploy/webstart - JNLP files won't launch from IE11 on Windows 10 Creators Update
    Web-start applications cannot be launched when clicking JNLP link from IE 11 on Windows 10 Creators Update when 64-bit JRE is installed. Workaround is to uninstall 64-bit JRE and use only 32-bit JRE.
  • This release also contains fixes for security vulnerabilities described in the Oracle Critical Patch Update. For a more complete list of the bug fixes included in this release, see the JDK 9.0.4 Bug Fixes page.
Versienummer 9.0.4
Releasestatus Final
Besturingssystemen Windows 7, Linux, macOS, Solaris, Windows Server 2008, Windows Server 2012, Windows 8, Windows 10
Website Oracle
Licentietype Freeware

Door Japke Rosink


25-01-2018 • 13:52

17 Linkedin

Submitter: sambalbaj

Bron: Oracle

Reacties (17)

Wijzig sortering
Is 9 backward compatible met 8?
Dus als je 9 installeert, draait iets dat Java 8 nodig heeft dan ook?
Nee, er zijn veel nieuwe (security) beperkingen en features in Java 9 waardoor het niet vanzelfsprekend is dat Java 8 apps gewoon draaien. Zo zijn er bijvoorbeeld veel sterkere restricties op de Reflection API.
Die beperkingen gelden voornamenlijk voor code die je op Java 9 wil compileren. Applicaties die netjes volgens de standaard geschreven zijn en geen low-level hacks gebruiken (bytecode manipulatie e.d.) zullen meestal werken.
In mijn ervaring breken veel in Java 8 gecompilede libraries/applicaties zodra je ze probeert te draaien op Java 9. Ik ben hier tegenaan gelopen met bijvoorbeeld Jetty, Cassandra en een aantal andere libraries die gebruik maken van reflection op private attributes om dingen gedaan te krijgen. Er is een setting om reflection toe te staan, maar het is me tot dusver niet gelukt die aan de praat te krijgen.

[Reactie gewijzigd door MrEyes op 25 januari 2018 17:10]

Ik heb Java nog nodig voor SportLink, de applicatie voor ledenadministratie voor (oa) knvb en knzb, maar gosh o gosh, kan dat spul nou niet eens een keer zelfupdatend gemaakt worden? Ik heb het idee dat ik élke week een nieuwe versie installeer
Beetje overdreven. De versie hiervoor van Java 9 (9.0.1) komt uit oktober 2017.

Ik snap niet dat er gekozen is voor Java Web Start voor de ledenadministratie en niet gewoon een webapplicatie. Het starten ervan vond ik al omslachtig:

En bij wachtwoord vergeten crasht ie. |:(
Interessant genoeg zie ik geen link naar de 32-bit versie meer, misschien omdat ik zelf 64-bit Windows met een 64-bit browser draai. Hij bestaat nog wel: als je in de link naar de 64-bit versie "x64" vervangt door "x86" krijg je de 32-bit versie.
'Oracle' Java? Is dat de manier van aanduiden sinds Java 9, of was dat altijd al?
Die benaming zijn ze vrij snel nadat Oracle Sun heeft overgenomen gaan gebruiken. Voorheen was het dan ook officieel Sun Java. Maar misschien probeert Oracle inmiddels iets prominenter zijn merknaam aan Java te verbinden? Ik heb er zelf nooit zo'n last van gehad, ik gebruik vrijwel overal de OpenJDK.
Als junior software engineer ben ik wel benieuwd; merk je veel verschillen en zou ik bepaalde dingen in acht moeten nemen voor openJDK VS Oracle? Updates als deze bijvoorbeeld, heeft openJDK dezelfde security patches of is de implementatie anders en hebben ze andere updates en security specs?
De Oracle JDK is gebaseerd op OpenJDK en bevat nog een aantal extra onderdelen. Voor sommige van deze moet je een licentie afsluiten voordat je ze in productiesituaties mag gebruiken (o.m. Java Mission Control en Flight Recorder)
Wauw dat is me echt nog nooit opgevallen.
An sich een prima verhaal over virusscanners en het vervangen van een oude pc, maar wat heeft dit alles met Java 9.0.4 te maken? xD Ik doe nog altijd het meeste van mijn programmeerwerk in Java, prima taaltje :)

[Reactie gewijzigd door job_h op 25 januari 2018 15:46]

Dat ik dus Java bij niemand meer installeer, net als flash, silverlight en shockwave player.

Het is voor de thuisgebruiker niet meer nodig, websites enzo doen allemaal zonder de plug-ins.
Ik zou graag het onderscheid willen maken tussen Java als geheel, en de Java Applets die in websites gebruikt werden. Oracle heeft zelf ook al een tijd door dat er betere opties zijn voor websites. Java als taal voor computer programma's vind ik echter niks mis mee :)

Als bewijs dat Oracle zelf ook door heeft dat er betere opties zijn: De Applet API, die door webbrowsers gebruikt kan worden, is deprecated sinds Java 9. Oracle heeft aangegeven deze nog nog niet te verwijderen in de volgende Java versie, maar dat dat er wel een keer gaat gebeuren. Zodra dat wel gebeurt kunnen websites het überhaupt niet meer gebruiken als iemand zijn Java versie update.

Edit: Ik kan me niet voorstellen dat het offtopic is om te melden dat de Applet API deprecated is sinds deze Java versie. Maar ach, dat zal aan mij liggen :)

[Reactie gewijzigd door job_h op 25 januari 2018 21:32]

Op dit item kan niet meer gereageerd worden.

Kies score Let op: Beoordeel reacties objectief. De kwaliteit van de argumentatie is leidend voor de beoordeling van een reactie, niet of een mening overeenkomt met die van jou.

Een uitgebreider overzicht van de werking van het moderatiesysteem vind je in de Moderatie FAQ.

Rapporteer misbruik van moderaties in Frontpagemoderatie.

Google Pixel 7 Sony WH-1000XM5 Apple iPhone 14 Samsung Galaxy Watch5, 44mm Sonic Frontiers Samsung Galaxy Z Fold4 Insta360 X3 Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack,, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2022 Hosting door True

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.


Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details


    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details