The XML Signature implementation has been updated to Santuario 3.0.3. Support for four new SHA-3 based RSA-MGF1 signature methods have been added: SHA3_224_RSA_MGF1, SHA3_256_RSA_MGF1, SHA3_384_RSA_MGF1, and SHA3_512_RSA_MGF1. While these new algorithm URIs are not defined in javax.xml.crypto.dsig.SignatureMethod in the JDK update releases, they may be represented as string literals in order to be functionally equivalent. SHA-3 hash algorithm support was delivered to JDK 9 via JEP 287. Releases earlier than that may use third party security providers.

Additionally, support for the following EdDSA signatures has been added: ED25519 and ED448. While these new algorithm URIs are not defined in javax.xml.crypto.dsig.SignatureMethod in the JDK Update releases, they may be represented as string literals in order to be functionally equivalent. The JDK supports EdDSA since JDK 15. Releases earlier than that may use 3rd party security providers. One other difference is that the JDK still supports the here() function by default. However, we recommend avoiding the use of the here() function in new signatures and replacing existing signatures that use the here() function. Future versions of the JDK will likely disable, and eventually remove, support for this function, as it cannot be supported using the standard Java XPath API. Users can now disable the here() function by setting the security property jdk.xml.dsig.hereFunctionSupported to "false".

The java.awt.SystemTray API is used for notifications in a desktop taskbar and may include an icon representing an application. On Linux, the Gnome desktop's own icon support in the taskbar has not worked properly for several years due to a platform bug. This, in turn, has affected the JDK's API, which relies upon that.

Therefore, in accordance with the existing Java SE specification, java.awt.SystemTray.isSupported() will return false where ever the JDK determines the platform bug is likely to be present.

The impact of this is likely to be limited since applications always must check for that support anyway. Additionally, some distros have not supported the SystemTray for several years unless the end-user chooses to install non-bundled desktop extensions.

The following root certificates have been added to the cacerts truststore:

+ Certainly

  + certainlyrootr1
    DN: CN=Certainly Root R1, O=Certainly, C=US
+ Certainly
  + certainlyroote1
    DN: CN=Certainly Root E1, O=Certainly, C=US

The XML Signature secure validation mode has been enabled by default (previously it was not enabled by default unless running with a security manager). When enabled, validation of XML signatures are subject to stricter checking of algorithms and other constraints as specified by the jdk.xml.dsig.secureValidationPolicy security property.

If necessary, and at their own risk, applications can disable the mode by setting the org.jcp.xml.dsig.secureValidation property to Boolean.FALSE with the DOMValidateContext.setProperty() API.

A new system property named org.jcp.xml.dsig.secureValidation has been added. It can be used to enable or disable the XML Signature secure validation mode. The system property should be set to "true" to enable, or "false" to disable. Any other value for the system property is treated as "false". If the system property is set, it supersedes the XMLCryptoContext property value.

Secure validation mode is enabled by default if you are running the code with a SecurityManager, otherwise it is disabled by default.

When the C1 compiler is the only compiler available to the VM, it applies loop predication to remove array access range checks from loop bodies. Due to a defect, this optimization was disabled, potentially leading to a performance regression.

This only affects the client VM or VM's running with the non-default command line flags -XX:+NeverActAsServerClassMachine or -XX:TieredStopAtLevel=[1,2,3].

On Linux, process memory information has been added to both JVM crash reports (hs_err files) and the VM.info diagnostic jcmd. This information contains the process' virtual size, its resident set size, and how much memory was swapped out. If the JVM uses glibc, the size of glibc outstanding allocations and retained memory are printed, as well as the glibc tunables.

The system property, jdk.jar.maxSignatureFileSize, allows applications to control the maximum size of signature files in a signed JAR. Its default value has been increased from 8000000 bytes (8 MB) to 16000000 bytes (16 MB).

The following root certificates have been added to the cacerts truststore:

+ DigiCert, Inc.

  + digicertcseccrootg5
    DN: CN=CN=DigiCert CS ECC P384 Root G5, O="DigiCert, Inc.", C=US

+ DigiCert, Inc.
  + digicertcsrsarootg5
    DN: CN=DigiCert CS RSA4096 Root G5, O="DigiCert, Inc.", C=US

+ DigiCert, Inc.
  + digicerttlseccrootg5
    DN: DigiCert TLS ECC P384 Root G5, O="DigiCert, Inc.", C=US

+ DigiCert, Inc.
  + digicerttlsrsarootg5
    DN: DigiCert TLS RSA4096 Root G5, O="DigiCert, Inc.", C=US

The following root certificates have been added to the cacerts truststore:

+ eMudhra Technologies Limited

  + emsignrootcag1
    DN: CN=emSign Root CA - G1, O=eMudhra Technologies Limited, OU=emSign PKI, C=IN

+ eMudhra Technologies Limited
  + emsigneccrootcag3
    DN: CN=emSign ECC Root CA - G3, O=eMudhra Technologies Limited, OU=emSign PKI, C=IN

+ eMudhra Technologies Limited
  + emsignrootcag2
    DN: CN=emSign Root CA - G2, O=eMudhra Technologies Limited, OU=emSign PKI, C=IN

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

+ Telia Root CA v2

  + teliarootcav2
    DN: CN=Telia Root CA v2, O=Telia Finland Oyj, C=FI

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

+ Let's Encrypt

  + letsencryptisrgx2
    DN: CN=ISRG Root X2, O=Internet Security Research Group, C=US

The (D)TLS implementation in JDK now calls X509KeyManager.chooseClientAlias() only once during handshaking for client authentication, even if there are multiple algorithms requested .

The system property, jdk.jar.maxSignatureFileSize, allows applications to control the maximum size of signature files in a signed JAR. Its default value has been increased from 8000000 bytes (8 MB) to 16000000 bytes (16 MB).

The -XshowSettings launcher option has been enhanced to print the tzdata version configured with the JDK. The tzdata version is displayed as part of the locale showSettings option.

Example output using -X:showSettings:locale:

.....

Locale settings:
    default locale = English
    default display locale = English
    default format locale = English
    tzdata version = 2023c
    .....

The following root certificate from SECOM Trust System has been removed from the cacerts keystore:

+ alias name "secomscrootca1 [jdk]"

  Distinguished Name: OU=Security Communication RootCA1, O=SECOM Trust.net, C=JP

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

+ Certigna (Dhimyotis)

  + certignarootca
    DN: CN=Certigna Root CA, OU=0002 48146308100036, O=Dhimyotis, C=FR

The installation directory of Oracle JDK Debian packages has changed. It was originally `/usr/lib/jvm/jdk-${FEATURE}`. With this release, it has been changed to `/usr/lib/jvm/jdk-${FEATURE}-oracle-${ARCH}`.

The Oracle JDK Debian package registers jexec as an interpreter for launching .jar files from the command line.

The Oracle JDK Debian package configures storage for Java Preferences API in the /etc/.java/.systemPrefs directory.

The Oracle JDK Debian package registers JDK commands with the update-alternatives command and supplies the /usr/lib/jvm/.jdk-${FEATURE}-oracle-${ARCH}.jinfo file for the update-java-alternatives command.

In JDK 12, two new token options for the java.security.manager system property, "allow" and "disallow", were introduced.

Many applications and frameworks are designed to run on multiple JDKs. For those that enable the SecurityManager at runtime via System.setSecurityManager, they have to specify the "allow" option as of JDK 18 (see JDK-8203316). However, these applications would also prefer to use the same command line across multiple versions of the JDK, especially if it is not known what JDK version a user will use.

Currently, if these options are specified in JDK 12 or earlier, the runtime attempts to load a SecurityManager implementation with the classname "allow" or "disallow", which results in a Could not create SecurityManager Error and the application will not start up.

From this release onward, the "allow" and "disallow" options for the java.security.manager system property will be ignored.

The JDK implementation of TLS 1.2 now uses a default Diffie Hellman keysize of 2048 bits when a TLS_DHE cipher suite is negotiated and either the client or server does not support FFDHE, which can negotiate a stronger keysize. The JDK TLS implementation supports FFDHE and it is enabled by default.

As a workaround, users can revert to the previous size by setting the jdk.tls.ephemeralDHKeySize system property to 1024 (at their own risk).

This change does not affect TLS 1.3 as the minimum DH group size is already 2048 bits.

For TLS connections, the cipher suite selection, by default, is updated to use the server cipher suites preference. Applications can configure the behavior by using the SSLParameters.setUseCipherSuitesOrder​() method.

The China National Standard body (CESI) has recently published GB18030-2022, which is an updated version of the GB18030 standard and brings GB18030 in sync with Unicode version 11.0. The purpose of this enhancement is to incorporate 5 code points (U+9FEB - U+9FEF) from Unicode 11.0 into Java SE 11 to allow implementations to comply with their Implementation Level 1 requirements.

The China National Standard body (CESI) has recently published GB18030-2022, which is an updated version of the GB18030 standard and brings GB18030 in sync with Unicode version 11.0. The Charset implementation for this new standard has now replaced the prior 2000 standard. However, this new standard has some incompatible changes from the prior implementation. For those who need to use the old mappings, a new system property, jdk.charset.GB18030, is introduced. By setting its value to 2000, the previous JDK releases' mappings for the GB18030 Charset are used, which are based on the 2000 standard.

The China National Standard body (CESI) has recently published GB18030-2022. This is an updated version of the GB18030 standard and brings GB18030 in sync with Unicode version 11.0. The purpose of this enhancement is to state that Java SE 11 supports the Implementation Level 2 of the GB18030-2022 standard.

The Windows KeyStore support in the SunMSCAPI provider has been expanded to include access to the local machine location. The new keystore types are:

• "Windows-MY-LOCALMACHINE"
• "Windows-ROOT-LOCALMACHINE"

The following keystore types were also added, allowing developers to make it clear they map to the current user:

• "Windows-MY-CURRENTUSER" (same as "Windows-MY")
• "Windows-ROOT-CURRENTUSER" (same as "Windows-ROOT")

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.

A new Java Flight Recorder (JFR) event has been added to record details of java.security.Provider.getService(String type, String algorithm) calls.

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

This event is disabled by default and can be enabled via the JFR configuration files or via standard JFR options.

RSA private and public keys in PKCS#1 format can now be accepted by JDK providers, such as the RSA KeyFactory.impl from the SunRsaSign provider. The RSA private or public key object should have the PKCS#1 format and an encoding matching the ASN.1 syntax for a PKCS#1 RSA private key and public key.

Installing into the same, shared jdk-(family) directory is the default behavior for the JDK starting with the July 2023 CPU. It could lead to FilesInUse issues if JDK files are locked by the "System User". We recommend shutting down any apps using the JDK as the "System User" before upgrading.

A new system property, jdk.nio.zipfs.allowDotZipEntry, has been introduced. This system property can be used to remove the newly added restrictions in the Zip FS provider, which currently rejects ZIP files that contain entries with "." or ".." in name elements by default. Refer to the CSR for more detail.

A regression where the /usr/java/default symlink is not created by RPM installers on Linux platforms has been fixed. Installers will create the /usr/java/default symlink if it doesn't exist, targeting the /usr/java/latest symlink.

The JDK RPM installer will remove incorrectly constructed entries of "java" and "javac" groups registered by older Oracle JDK RPM installers from the alternatives before registering new "java" and "javac" entries.

An incorrectly constructed entry of the "java" group contains commands that are supposed to belong to the "javac" group.

An incorrectly constructed entry of the "javac" group contains commands that are supposed to belong to the "java" group.

All incorrectly constructed entries belonging to Oracle JDK RPM packages will be removed from the alternatives to avoid corruption of the alternatives internal data.

The removal has a potential side effect for users who have installed multiple JDK versions that are not updated to the latest release. Commands from a removed "java" or "javac" group are now unavailable for system Java switch, which potentially changes the current system Java without a warning. For example, if there is an out-of-date JDK RPM from an 11+ release, say 11.0.17, with an incorrectly constructed single "java" group installed and 8u381 RPM with this patch is installed, it will remove an entry from the "java" group belonging to the 11.0.17 RPM and thus will switch the current system Java from 11.0.17 to 8u381. The side effect will only happen when you install a lower JDK family with the fix, such as 8u381, and there is an out-of-date JDK from a higher family, such as 11.0.17, installed on the system. In that case, 8u381 will replace the older 11.0.17 as the latest. The remedy for the user is to install the latest JDK 11.

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

+ TWCA

  + twcaglobalrootca
    DN: CN=TWCA Global Root CA, OU=Root CA, O=TAIWAN-CA, C=TW

The following root certificates have been added to the cacerts truststore:

+ Google Trust Services LLC

 + gtsrootcar1
  DN: CN=GTS Root R1, O=Google Trust Services LLC, C=US

+ Google Trust Services LLC
 + gtsrootcar2
  DN: CN=GTS Root R2, O=Google Trust Services LLC, C=US

+ Google Trust Services LLC
 + gtsrootecccar3
  DN: CN=GTS Root R3, O=Google Trust Services LLC, C=US

+ Google Trust Services LLC
 + gtsrootecccar4
  DN: CN=GTS Root R4, O=Google Trust Services LLC, C=US

The following root certificates have been added to the cacerts truststore:

+ Microsoft Corporation

  + microsoftecc2017
    DN: CN=Microsoft ECC Root Certificate Authority 2017, O=Microsoft Corporation, C=US

+ Microsoft Corporation
  + microsoftrsa2017
    DN: CN=Microsoft RSA Root Certificate Authority 2017, O=Microsoft Corporation, C=US

This JDK implements Maintenance Release 2 of the Java SE 11 specification (JSR 384). This is indicated by the new system property java.specification.maintenance.version having the value of "2".

A virtual machine crash was observed in JDK 11.0.19 and 17.0.7 when executing the GregorianCalender.computeTime() method (JDK-8307683). It was found that although the root cause of the crash is an old issue, a recent fix for a rare issue in the C2 compiler (JDK-8297951) made the crash much more likely. To mitigate this, the fix has been reverted in JDK 11.0.20 and 17.0.8 and will be reapplied once JDK-8307683 is resolved.

Starting with the July 2023 CPU, on operating systems where ASLR (Address Space Layout Randomization) is enabled, the CDS archive will be placed at a random address picked by the operating system.

This change may have a minor performance impact: (a) Start-up time may increase because the JVM needs to patch pointers inside the CDS archive. (b) Memory usage may increase because the memory used by the CDS archive is no longer shareable across processes. We expect the impact to be small because such increases should be only a small fraction of the overall application usage.

In the unlikely event that you must disable ASLR for CDS, you can use the JVM flags -XX:+UnlockDiagnosticVMOptions -XX:ArchiveRelocationMode=0. The usage of such flags is not recommended.

A behavioral change has been made when 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.

A new system property, jdk.jar.maxSignatureFileSize, has been added to allow applications to control the maximum size of signature files in a signed JAR. The value of the system property is the desired size in bytes. The default value is 8000000 bytes.

java.util.zip.ZipFile has been updated to provide additional validation of ZIP64 extra fields when opening a ZIP file. This validation may be disabled by setting the system property jdk.util.zip.disableZip64ExtraFieldValidation to true.

A native GSS-API library named sspi_bridge.dll has been added to the JDK on the Windows platform. The library is client-side only and uses the default credentials. It will be loaded when the sun.security.jgss.native system property is set to "true". A user can still load a third-party native GSS-API library by setting the sun.security.jgss.lib system property to its path.

Native GSS automatically uses cached credentials from operating systems, thus the javax.security.auth.useSubjectCredsOnly system property should be set to false.

com.sun.security.auth.module.Krb5LoginModule does not call native JGSS. Avoid using com.sun.security.auth.module.Krb5LoginModule from JAAS config.

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

SSLv2Hello and SSLv3 have been removed from the default enabled TLS protocols.

After this update, if SSLv3 is removed from the jdk.tls.disabledAlgorithms security property, the SSLSocket.getEnabledProtocols(), SSLServerSocket.getEnabledProtocols(), SSLEngine.getEnabledProtocols() and SSLParameters.getProtocols() APIs will return "TLSv1.3, TLSv1.2, TLSv1.1, TLSv1". "SSLv3" will not be returned in this list.

If a client or server still needs to use the SSLv3 protocol they can do so by enabling it through the jdk.tls.client.protocols or jdk.tls.server.protocols system properties or with the SSLSocket.setEnabledProtocols(), SSLServerSocket.setEnabledProtocols() and SSLEngine.setEnabledProtocols() APIs.

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 the previous releases and also ensures that the method is consistent with the root directories in the iteration returned by FileSystem.getDefault().getRootDirectories().

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.

• Palestine transitions are now Saturdays at 02:00.
• Simplify three Ukraine zones into one.
• Jordan and Syria switch from +02/+03 with DST to year-round +03.
• Mexico will no longer observe DST except near the US border.
• Chihuahua moves to year-round -06 on 2022-10-30.
• Fiji no longer observes DST.
• Move links to 'backward'.
• In vanguard form, GMT is now a Zone and Etc/GMT a link.
• zic now supports links to links, and vanguard form uses this.
• Simplify four Ontario zones.
• Fix a Y2438 bug when reading TZif data.
• Enable 64-bit time_t on 32-bit glibc platforms.
• Omit large-file support when no longer needed.
• In C code, use some C23 features if available.
• Remove no-longer-needed workaround for Qt bug 53071.

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.

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 11.0.18, and 11.0.19 releases for x64 will both be installed in /usr/lib/jvm/jdk-11-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 11 RPM package registers java and javac groups with the alternatives framework. java group is for commands used to run applications: java, jjs, keytool, pack200, rmid, rmiregistry, unpack200. 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-11-headless and jdk-11-headful. These packages are available in OL7, OL8, and OL9 repositories. They are not available for OTN downloads. jdk-11-headless is a Headless Java Runtime for running non-GUI applications. jdk-11-headful is a Headful Java Runtime & Development Tools for developing and running applications of all types.

The combination of the OL-specific jdk-11-headless and jdk-11-headful packages provides the same JDK image and the same capabilities as jdk-11 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 11.0.18 and 11.0.19 releases will both install into %Program Files%\Java\jdk-11 by default, and they both cannot be installed at the same time.

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

If the JDK11.0.18 installer is launched when JDK11.0.19 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 11.0.18 and 11.0.19 releases will both install into the /Library/Java/JavaVirtualMachines/jdk-11.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 11.0.N update releases shipped prior JEP C208 will not be uninstalled during installation of JDK 11 update release with JEP C208. However, JDK 11 GA release will be removed and its location /Library/Java/JavaVirtualMachines/jdk-11.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.

The default MAC algorithm used in a PKCS #12 keystore has been updated. The new algorithm is based on SHA-256 and is stronger than the old one based on SHA-1. See the security properties starting with keystore.pkcs12 in the java.security file for detailed information.

The new SHA-256 based MAC algorithms were introduced in the 11.0.12, 8u301, and 7u311 JDK versions. Keystores created using this newer, stronger, MAC algorithm cannot be opened in JDK versions earlier than 11.0.12, 8u301, and 7u311. A 'java.security.NoSuchAlgorithmException' exception will be thrown in such circumstances.

For compatibility, use the keystore.pkcs12.legacy system property, which will revert the algorithms to use the older, weaker algorithms. There is no value defined for this property.

It is now possible to monitor deserialization of objects using JDK Flight Recorder (JFR). When JFR is enabled and the JFR configuration includes deserialization events, JFR will emit an event whenever the running program attempts to deserialize an object. The deserialization event is named jdk.Deserialization, and it is disabled by default. The deserialization event contains information that is used by the serialization filter mechanism; see the ObjectInputFilter specification. Additionally, if a filter is enabled, the JFR event indicates whether the filter accepted or rejected deserialization of the object. For further information about how to use the JFR deserialization event, see the article Monitoring Deserialization to Improve Application Security. For reference information about using and configuring JFR, see the JFR Runtime Guide and JFR Command Reference sections of the JDK Mission Control documentation.

JARs signed with SHA-1 algorithms are now restricted by default and treated as if they were unsigned. This applies to the algorithms used to digest, sign, and optionally timestamp the JAR. It also applies to the signature and digest algorithms of the certificates in the certificate chain of the code signer and the Timestamp Authority, and any CRLs or OCSP responses that are used to verify if those certificates have been revoked. These restrictions also apply to signed JCE providers.

To reduce the compatibility risk for JARs that have been previously timestamped, there is one exception to this policy:

• Any JAR signed with SHA-1 algorithms and timestamped prior to January 01, 2019 will not be restricted.

This exception may be removed in a future JDK release. To determine if your signed JARs are affected by this change, run jarsigner -verify -verbose -certs on the signed JAR, and look for instances of "SHA1" or "SHA-1" and "disabled" and a warning that the JAR will be treated as unsigned in the output.

For example:

-  Signed by "CN="Signer""

     Digest algorithm: SHA-1 (disabled)
     Signature algorithm: SHA1withRSA (disabled), 2048-bit key

WARNING: The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled by the security property:

  jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024, SHA1 denyAfter 2019-01-01

JARs affected by these new restrictions should be replaced or re-signed with stronger algorithms.

Users can, at their own risk, remove these restrictions by modifying the java.security configuration file (or override it by using the java.security.properties system property) and removing "SHA1 usage SignedJAR & denyAfter 2019-01-01" from the jdk.certpath.disabledAlgorithms security property and "SHA1 denyAfter 2019-01-01" from the jdk.jar.disabledAlgorithms security property.

The des3-hmac-sha1 and rc4-hmac Kerberos encryption types (etypes) are now deprecated and disabled by default. Users can set allow_weak_crypto = true in the krb5.conf configuration file to re-enable them (along with other weak etypes including des-cbc-crc and des-cbc-md5) at their own risk. To disable a subset of the weak etypes, users can list preferred etypes explicitly in any of the default_tkt_enctypes, default_tgs_enctypes, or permitted_enctypes settings.

Two system properties have been added which control the keep alive behavior of HttpURLConnection in the case where the server does not specify a keep alive time. Two properties are defined for controlling connections to servers and proxies separately. They are http.keepAlive.time.server and http.keepAlive.time.proxy respectively. More information about them can be found in Networking Properties.

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.

This version includes changes from 2022b that merged multiple regions that have the same timestamp data post-1970 into a single time zone data. All time zone IDs remain the same but the merged time zones will point to a shared zone data.

As a result, pre-1970 data may not be compatible with earlier JDK versions. The affected zones are Antarctica/Vostok, Asia/Brunei, Asia/Kuala_Lumpur, Atlantic/Reykjavik, Europe/Amsterdam, Europe/Copenhagen, Europe/Luxembourg, Europe/Monaco, Europe/Oslo, Europe/Stockholm, Indian/Christmas, Indian/Cocos, Indian/Kerguelen, Indian/Mahe, Indian/Reunion, Pacific/Chuuk, Pacific/Funafuti, Pacific/Majuro, Pacific/Pohnpei, Pacific/Wake, Pacific/Wallis, Arctic/Longyearbyen, Atlantic/Jan_Mayen, Iceland, Pacific/Ponape, Pacific/Truk, and Pacific/Yap.

For more details, refer to the announcement of 2022b.

A new system property named jdk.httpserver.maxConnections has been introduced to allow users to configure the com.sun.net.httpserver.HttpServer to limit the maximum number of open connections to the server at any given time. This system property takes an integer value and can be configured to be a positive integer. If the property is absent, set to 0, or a negative value, the server will not limit the number of open connections. By default, this system property is not set.

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 11.0.16.1) be used after the next critical patch update scheduled for October 18, 2022.

Oracle recommends that all JDK 11 users, even those that have already updated to 11.0.16, uptake the 11.0.16.1 patch release.

Fixes a regression in the C2 JIT compiler which caused the Java Runtime to crash unpredictably.

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 11.0.16) 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 on 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".

On oracle.com and java.com, certain JDK bundle extensions are getting truncated on download when using Firefox version 102. The downloaded bundles have no file extension like ".exe", ".rpm", ".deb". If you are not able to upgrade to Firefox ESR 102.0.1 or Firefox 103 when it is released, then as a workaround you can:

• manually add a file extension to the file name after download.
• use a different browser

java.util.Vector is updated to correctly report ClassNotFoundException that occurs during deserialization using java.io.ObjectInputStream.GetField.get(name, object)when the class of an element of the Vector is not found. Without this fix, a StreamCorruptedException is thrown that does not provide information about the missing class.

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.

The Windows implementation of java.io.File allows access to NTFS Alternate Data Streams (ADS) by default. Such streams have a structure like “filename:streamname”. A system property jdk.io.File.enableADS has been added to control this behavior. To disable ADS support in java.io.File, the system property jdk.io.File.enableADS should be set to false (case ignored). Stricter path checking however prevents the use of special devices such as NUL:

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

ChaCha20 KeyGenerator <=> CKM_CHACHA20_KEY_GEN mechanism

CHACHA20-POLY1305 Cipher <=> CKM_CHACHA20_POLY1305 mechanism  
CHACHA20-POLY1305 AlgorithmParameters <=> CKM_CHACHA20_POLY1305 mechanism  
CHACHA20 SecretKeyFactory <=> CKM_CHACHA20_POLY1305 mechanism

        TransformerFactory factory = TransformerFactory.newInstance();

        factory.setAttribute("jdk.xml.xpathTotalOpLimit", "1000");

        System.setProperty("jdk.xml.xpathExprGrpLimit", "20");

        jdk.xml.xpathExprGrpLimit=20

  -Dcom.sun.jndi.ldapURLParsing="legacy" | "compat" | "strict"    (to control "ldap:" URLs)

  -Dcom.sun.jndi.dnsURLParsing="legacy" | "compat" | "strict"     (to control "dns:" URLs)
  -Dcom.sun.jndi.rmiURLParsing="legacy" | "compat" | "strict"     (to control "rmi:" URLs)

• Jordan now starts DST on February's last Thursday.
• Samoa no longer observes DST.
• Merge more location-based Zones whose timestamps agree since 1970.
• Move some backward-compatibility links to 'backward'.
• Rename Pacific/Enderbury to Pacific/Kanton.
• Correct many pre-1993 transitions in Malawi, Portugal, etc.
• zic now creates each output file or link atomically.
• zic -L no longer omits the POSIX TZ string in its output.
• zic fixes for truncation and leap second table expiration.
• zic now follows POSIX for TZ strings using all-year DST.
• Fix some localtime crashes and bugs in obscure cases.
• zdump -v now outputs more-useful boundary cases.
• tzfile.5 better matches a draft successor to RFC 8536.
• A new file SECURITY.
• Revert most 2021b changes to 'backward'.
• Fix 'zic -b fat' bug in pre-1970 32-bit data.
• Fix two Link line typos.
• Distribute SECURITY file.

This release is intended as a bugfix release, to fix compatibility problems and typos reported since 2021b was released.

• Fiji suspends DST for the 2021/2022 season.
• 'zic -r' marks unspecified timestamps with "-00".
• Palestine will fall back 10-29 (not 10-30) at 01:00.

SunPKCS11 provider adds new provider configuration attributes to better control native resources usage. The SunPKCS11 provider consumes native resources in order to work with native PKCS11 libraries. To manage and better control the native resources, additional configuration attributes are added to control the frequency of clearing native references as well as whether to destroy the underlying PKCS11 Token after logout.

The 3 new attributes for SunPKCS11 provider configuration file are:

1. destroyTokenAfterLogout (boolean, defaults to false)

   If set to true, when java.security.AuthProvider.logout() is called upon the SunPKCS11 provider instance, the underlying Token object will be destroyed and resources will be freed. This essentially renders the SunPKCS11 provider instance unusable after logout() calls. Note that a PKCS11 provider with this attribute set to true should not be added to the system provider list since the provider object is not usable after a logout() method call.

2. cleaner.shortInterval (integer, defaults to 2000, in milliseconds)

   This defines the frequency for clearing native references during busy period (such as, how often should the cleaner thread processes the no-longer-needed native references in the queue to free up native memory). Note that the cleaner thread will switch to the 'longInterval' frequency after 200 failed tries (such as, when no references are found in the queue).

3. cleaner.longInterval (integer, defaults to 60000, in milliseconds)

   This defines the frequency for checking native reference during non-busy period (such as, how often should the cleaner thread check the queue for native references). Note that the cleaner thread will switch back to the 'shortInterval' value if native PKCS11 references for cleaning are detected.

Two new system properties have been added. The system property, jdk.tls.client.disableExtensions, is used to disable TLS extensions used in the client. The system property, jdk.tls.server.disableExtensions, is used to disable TLS extensions used in the server. If an extension is disabled, it will be neither produced nor processed in the handshake messages.

The property string is a list of comma separated standard TLS extension names, as registered in the IANA documentation (for example, server_name, status_request, and signature_algorithms_cert). Note that the extension names are case sensitive. Unknown, unsupported, misspelled and duplicated TLS extension name tokens will be ignored.

Please note that the impact of blocking TLS extensions is complicated. For example, a TLS connection may not be able to be established if a mandatory extension is disabled. Please do not disable mandatory extensions, and do not use this feature unless you clearly understand the impact.

The following root certificate from Google has been removed from the cacerts keystore:

+ alias name "globalsignr2ca [jdk]"

  Distinguished Name: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2

The ZIP file system provider has been changed to reject existing ZIP files that contain entries with "." or ".." in name elements. ZIP files with these entries cannot be used as a file system. Invoking the java.nio.file.FileSystems.newFileSystem(...) methods throw ZipException if the ZIP file contains these entries.

IANA Time Zone Database, on which JDK's Date/Time libraries are based, has made a tweak to some time zone rules since 2021c. Note that since this update, some of the time zone rules prior to the year 1970 have been modified according to the changes which were introduced with 2021b. For more detail, refer to the announcement of 2021b

A new JNDI environment property “com.sun.jndi.ldap.tls.cbtype” has been added to enable TLS Channel Binding data in LDAP authentication over SSL/TLS protocol to the Windows AD server. A possible value is “tls-server-end-point” - Channel Binding data is created on the base of the TLS server certificate. See the module description of the java.naming module.

This release reverts the behavior of SSLSocketImpl and SSLTransport introduced by JDK-8196584. SocketException will now be thrown as is instead of being suppressed into an SSLException.

For JVMs running in a container, OperatingSystemMXBean.getProcessCpuLoad now considers only the CPU resources available to the container when calculating CPU load. Prior to this change, the calculation included all CPUs on a host. After this change, management agents may report higher CPU usage by JVMs in containers that are constrained to a limited set of CPUs.

For more information, refer to Timezone Data Versions in the JRE Software.

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

+ alias name "identrustdstx3 [jdk]"

  Distinguished Name: CN=DST Root CA X3, O=Digital Signature Trust Co.