Oracle recommends that the JDK is updated with each Critical Patch Update. In order to determine if a release is the latest, the Security Baseline page can be used to determine which is the latest version for each release family.

Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Bulletins. It is not recommended that this JDK (version 17.0.4) be used after the next critical patch update scheduled for October 18, 2022.

Support has been added for TLS channel binding tokens for Negotiate/Kerberos authentication over HTTPS through javax.net.HttpsURLConnection.

Channel binding tokens are increasingly required as an enhanced form of security which can mitigate certain kinds of socially engineered, man in the middle (MITM) attacks. They work by communicating from a client to a server the client's understanding of the binding between connection security (as represented by a TLS server cert) and higher level authentication credentials (such as a username and password). The server can then detect if the client has been fooled by a MITM and shutdown the session/connection.

The feature is controlled through a new system property jdk.https.negotiate.cbt which is described fully in the Networking Properties page.

The java.net.InetAddress class has been updated to strictly accept IPv4 address literals in decimal quad notation. The InetAddress class methods are updated to throw an java.net.UnknownHostException for invalid IPv4 address literals. To disable this check, the new "jdk.net.allowAmbiguousIPAddressLiterals" system property can be set to "true".

DeflaterOutputStream.close() and GZIPOutputStream.finish() methods have been modified to close out the associated default JDK compressor before propagating a Throwable up the stack. ZIPOutputStream.closeEntry() method has been modified to close out the associated default JDK compressor before propagating an IOException, not of type ZipException, up the stack.

Previous JDK releases used an incorrect interpretation of the Linux cgroups parameter "cpu.shares". This might cause the JVM to use fewer CPUs than available, leading to an under utilization of CPU resources when the JVM is used inside a container.

Starting from this JDK release, by default, the JVM no longer considers "cpu.shares" when deciding the number of threads to be used by the various thread pools. The -XX:+UseContainerCpuShares command-line option can be used to revert to the previous behavior. This option is deprecated and may be removed in a future JDK release.