The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 17.0.7 are specified in the following table:

A new Java Flight Recorder (JFR) event has been added to record details of initial security properties when loaded via the java.security.Security class.

The new event name is jdk.InitialSecurityProperty and contains the following fields:

This new JFR event is enabled by default. The java.security.debug=properties system property will also now print initial security properties to the standard error stream. With this new event and the already available jdk.SecurityPropertyModification event (when enabled since it is not enabled by default), a JFR recording can now monitor the initial settings of all security properties and any subsequent changes.

Some Swing components, such as JLabels and JButtons, which display application text, will try to interpret that text as HTML, principally to enable styled text. The HTML processing of the text for these components will no longer recognize the <object> tag which allows for subclasses of java.awt.Component to be rendered on the component. To re-enable this, applications must specify -Dswing.html.object=true.

The following root certificate has been added to the cacerts truststore:

+ Certigna (Dhimyotis)
   + certignaca
      DN: CN=Certigna, O=Dhimyotis, C=FR

The behavior of the method java.io.File.listRoots() on Microsoft Windows has changed in this release so that the returned array includes a File object for all available disk drives. This differs from the behavior in JDK 10 to JDK 20, where this method filtered out disk drives that were not accessible or did not have media present. This change avoids performance issues observed in these releases and also ensures that the method is consistent with the root directories in the iteration returned by FileSystem.getDefault().getRootDirectories().

A behavioral change has been made in the case where the default conf/security/java.security security configuration file fails to load. In such a scenario, the JDK will now throw an InternalError.

Such a scenario should never occur. The default security file should always be present. Prior to this change, a static security configuration was loaded.

Applications using the Dell BSAFE Crypto-J 3rd party security provider may encounter an IOException if decoding DH or DSA algorithm parameters with the following exception:

Exception in thread "main" java.io.IOException: Could not decode parameters. at com.rsa.cryptoj.o.ms.engineInit(Unknown Source) at java.security.AlgorithmParameters.init(AlgorithmParameters.java:293)

Dell BSAFE Crypto-J version 6.2.6.2 has been released to address this issue. Applications using this provider should upgrade to that version or later. For applications on older versions of this provider, an interoperability fix has been added to this release of the JDK.