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.6) be used after the next critical patch update scheduled for April 18, 2023.

With this fix the SunJSSE DTLS implementation will by default exchange cookies for all handshakes (new and resumed) unless the System property jdk.tls.enableDtlsResumeCookie is false. The property only affects the cookie exchange for resumption.

An OCSP response signed with the RSASSA-PSS algorithm is now supported.

This issue prevents yum from automatically installing the correct packages required by Oracle Linux specific x86_64 headless and headful JDK packages. Instead of x86_64 packages, it will install i686 packages. To workaround the issue, you may manually install packages with the same names as indicated by yum but with the x86_64 architecture.

After you have the x86_64 headless and/or headful jdk packages installed, you can get the list of required x86_64 packages by running the following script:

rpm -qa | grep -E -e '^jdk-.*-headful-.*\.x86_64$' -e '^jdk-.*-headless-.*\.x86_64$' | xargs -r rpm -q --requires | sort -u | cut -d ' ' -f 1 | grep -v '^rpmlib' | xargs -r rpm -q --whatprovides | sort -u | grep -e '.i[3456]86$' | xargs -r rpm -q --queryformat '%{name}.x86_64\n' | xargs -r echo

It will output a space-separated list of names of required x86_64 packages to stdout. You can pass this list to a sudo yum install command to ensure the installation of the required packages.

The “JavaScript script engine” for FXML is now disabled by default. Any .fxml file that has a "javascript" Processing Instruction (PI) will no longer load by default, and an exception will be thrown.

If the JDK has a JavaScript script engine, it can be enabled by setting the system property: -Djavafx.allowjs=true

With 11.0.14, we are shipping the original JDK 11 translated resource bundles for German.

Installation directory name of Oracle JDK in RPM package has changed from /usr/java/jdk-${VERSION} to /usr/lib/jvm/jdk-${FEATURE}-oracle-${ARCH}. Thus the 17.0.6, and 17.0.7 releases for x64 will both be installed in /usr/lib/jvm/jdk-17-oracle-x64 directory. RPM package will create /usr/java/jdk-${FEATURE} link pointing to the installation directory for backward compatibility.

Communication with the alternatives framework of JDK RPM package has changed. JDK RPM packages of prior versions registered a single java group of commands with the alternatives framework. The JDK 17 RPM package registers java and javac groups with the alternatives framework. java group is for commands used to run applications: java, keytool, and rmiregistry. javac group is used for all other commands. The set of commands registered by the package has not changed.

Two new Oracle Linux (OL)-specific JDK RPM packages have been added: jdk-17-headless and jdk-17-headful. These packages are available in OL7, OL8, and OL9 repositories. They are not available for OTN downloads. jdk-17-headless is a Headless Java Runtime for running non-GUI applications. jdk-17-headful is a Headful Java Runtime & Development Tools for developing and running applications of all types.

The combination of the OL-specific jdk-17-headless and jdk-17-headful packages provides the same JDK image and the same capabilities as jdk-17 OTN package. OL-specific JDK RPM packages specify required capabilities, and the "Release" property of these packages has a %{dist} suffix.

Windows JDK installers must install the Oracle JDK in %Program Files%\Java\jdk-%FEATURE% instead of %Program Files%\Java\jdk-%VNUM%. I.e. all updates of the same release must share one installation directory.

Thus the 17.0.6 and 17.0.7 releases will both install into %Program Files%\Java\jdk-17 by default, and they both cannot be installed at the same time.

If the JDK17.0.7 installer is launched when JDK17.0.6 is already installed, it will auto-upgrade them to JDK17.0.7. There may be a Files In Use dialog shown if the older version was running and locking JDK files.

If the JDK17.0.6 installer is launched when JDK17.0.7 is already installed, it will show an error that a newer version of this JDK family is already installed.

The Oracle JDK installation directory name will be changed from /Library/Java/JavaVirtualMachines/jdk-${VERSION}.jdk to /Library/Java/JavaVirtualMachines/jdk-${FEATURE}.jdk. Thus the 17.0.6 and 17.0.7 releases will both install into the /Library/Java/JavaVirtualMachines/jdk-17.jdk installation directory. Installing an older JDK update release will log an error, and not install the JDK, if a newer version of the same feature release already exists. An error dialog will be shown except in the case of a silent installation. JDK 17.0.N update releases shipped prior JEP C208 will not be uninstalled during installation of JDK 17 update release with JEP C208. However, JDK 17 GA release will be removed and its location /Library/Java/JavaVirtualMachines/jdk-17.jdk will be reused.

ProcessBuilder on Windows is restored to address a regression caused by JDK-8250568. Previously, an argument to ProcessBuilder that started with a double-quote and ended with a backslash followed by a double-quote was passed to a command incorrectly and may cause the command to fail. For example the argument "C:\\Program Files\", would be seen by the command with extra double-quotes. This update restores the long standing behavior that does not treat the backslash before the final double-quote specially.

The Set implementation that holds principals and credentials in a JAAS Subject prohibits null elements and any attempt to add, query, or remove a null element will result in a NullPointerException. This is especially important when trying to remove principals or credentials from the subject at the logout phase but they are null because of a previous failed login. Various JDK LoginModule implementations have been fixed to avoid the exception. An Implementation Note has also been added to the logout() method of the LoginModule interface. Developers should verify and if necessary update any custom LoginModule implementations to be compliant with this implementation advice.

As part of ongoing maintenance, the JDK for Windows is built using the Microsoft Visual Studio 2022 toolchain starting with this release.

If you have issues with a Java application and if you have native or JNI libraries that are compiled with a different release of the compiler, then you must consider compatibility issues between the runtimes. Specifically, your environment is supported only if you follow the Microsoft guidelines when dealing with multiple runtimes.