RELEASE NOTES: JDK 19

Indy String Concat Changes Order of Operations

String concatenation has been changed to evaluate each argument and eagerly convert it to a string, in left-to-right order. This fixes a bug in the invokedynamic-based string concatentation strategies introduced in JEP 280.

For example, the following now prints "foofoobar", not "foobarfoobar":

` StringBuilder builder = new StringBuilder("foo"); System.err.println("" + builder + builder.append("bar")); `

Lambda Deserialization Fails for Object Method References on Interfaces

Deserialization of serialized method references to Object methods, which was using an interface as the type on which the method is invoked, can now be deserialized again. Note the classfiles need to be recompiled to allow the deserialization.

JShell Highlights Deprecated Elements, Variables, and Keywords

JShell now marks deprecated elements and highlights variables and keywords in the console.

MD5 and SHA-1 Are Disabled by Default for HTTP Digest Authentication

The MD5 and SHA-1 message digest algorithms have been disabled by default for HTTP Digest authentication. MD5 and SHA-1 are considered insecure and are deprecated generally. Accordingly, they have both been disabled by default for some usages of HTTP Digest authentication with java.net.HttpURLConnection. They can re-enabled on an opt-in basis by setting a new system property. More information can be found in Networking Properties.

HTTPS Channel Binding Support for Java GSS/Kerberos

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. 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 or connection.

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

Improved HTTP Proxy Detection on Windows

When multiple Windows proxy configuration options are available, proxy selector now attempts all options in sequence until a proxy is selected or all options have been tried. Previously, only the first option was tried. For example, if automatic proxy detection was enabled, manual proxy setup was never used.

Make HttpURLConnection Default Keep Alive Timeout Configurable

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.

jstatd No Longer Requires a SecurityManager

jstatd no longer requires a Security Manager and policy file. Running with -Djava.security.policy= to set a policy has no effect.

Internally to jstatd, an ObjectInputFilter is used to allow only essential classes to be deserialized over the RMI connection.

Support for CLDR Version 41

Locale data based on Unicode Consortium's CLDR has been upgraded to version 41. For the detailed locale data changes, please refer to the Unicode Consortium's CLDR release notes.

Deprecation of Locale Class Constructors

New Locale.of() factory methods replace deprecated Locale constructors. The factory methods are efficient and reuse existing Locale instances. Locales are also provided by Locale.forLanguageTag() and Locale.Builder.

Support Unicode 14.0

This release upgrades Unicode support to 14.0, which includes the following:

The java.lang.Character class supports Unicode Character Database of 14.0 level, which adds 838 characters, for a total of 144,697 characters. These additions include 5 new scripts, for a total of 159 scripts, as well as 37 new emoji characters. The java.text.Bidi and java.text.Normalizer classes support 14.0 level of Unicode Standard Annexes, #9 and #15, respectively. The java.util.regex package supports Extended Grapheme Clusters based on 14.0 level of Unicode Standard Annex #29 For more detail about Unicode 14.0, refer to the Unicode Consortium's release note.

System Property for Java SE Specification Maintenance Version

The java.specification.maintenance.version system property is defined to indicate the maintenance release number of the Java SE specification being implemented by the JDK. If the implemented specification has not undergone a maintenance release, the value of system property is not set.

Double.toString(double) and Float.toString(float) may Return Slightly Different Results

The specification of these methods is now tighter than in earlier releases and the new implementation fully adheres to it.

As a consequence, some returned strings are now shorter than when using earlier releases, and for inputs at the extremes of the subnormal ranges near zero, might look differently. However, the number of cases where there's a difference in output is quite small compared to the sheer number of possible double and float inputs.

One example is Double.toString(2e23), which now returns "2.0E23", whereas in earlier releases it returns "1.9999999999999998E23". Another example, in the double subnormal range, is Double.toString(1e-323) which now returns "9.9E-324", as mandated by the new specification.

Incorrect Handling of Quoted Arguments in ProcessBuilder

ProcessBuilder on Windows is restored to its previous functionality 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 as a command incorrectly and may have caused the command to fail. For example the argument "C:\\Program Files\", would be seen as a command with extra double-quotes. This update restores the long standing behavior that does not treat the backslash before the final double-quote specially.

New System Properties for `System.out` and `System.err`

Two new system properties, stdout.encoding and stderr.encoding, have been added. The value of these system properties is the encoding used by the standard output and standard error streams (System.out and System.err).

The default values of these system properties depend on the platform. The values take on the value of the native.encoding property when the platform does not provide streams for the console. The properties can be overridden on the launcher's command line option (with -D) to set them to UTF-8 where required.

User's Home Directory set to $HOME if Invalid

On Linux and macOS, the system property user.home is set to the home directory provided by the operating system. If the directory name provided is empty or only a single character, the value of the environment variable HOME is used instead.

The directory name and the value of $HOME are usually the same and valid. The fallback to $HOME is unusual and unlikely to occur except in environments such as systemd on Linux or when running in a container such as Docker.

Metal Is now the Default Java 2D Rendering Pipeline on macOS

Previously JDK desktop applications using Swing and Java2D (tm) would render using OpenGL on macOS. As of this release of JDK, they now are rendered using Apple's new Metal accelerated graphics API. This has been available since JDK 17 (JEP 382), but was not automatically enabled. Now it is enabled by default. Applications will not need to take any action, as they will automatically benefit from faster graphics with lower power consumption, and the use of a more modern stable graphics API which will be able to work better on current and future Apple Mac systems. Any user who would prefer to continue to use OpenGL whilst it is still supported can disable rendering with Metal by starting their application with either "java -Dsun.java2d.metal=false" or "java -Dsun.java2d.opengl=true" and it will run with OpenGL as it used to in JDK 17.

-Xss may be Rounded up to a Multiple of the System Page Size

The actual java thread stack size may differ from the value specified by -Xss command line option; it may be rounded up to a multiple of the system page size when required by the operating system.

Automatic Generation of the CDS Archive

The JVM option -XX:+AutoCreateSharedArchive can be used to automatically create or update a CDS archive for an application. For example:

java -XX:+AutoCreateSharedArchive -XX:SharedArchiveFile=app.jsa -cp app.jar App

The specified archive will be written if it does not exist, or if it was generated by a different version of the JDK.

CPU Shares Ignored When Computing Active Processor Count

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.

JNI GetVersion Returns JNI_VERSION_19

The Java Native Interface function GetVersion has been changed in this release to return JNI_VERSION_19 (value 0x00130000).

New Methods to Create Preallocated HashMaps and HashSets

New static factory methods have been introduced to allow creation of HashMap and related instances that are preallocated to accommodate an expected number of mappings or elements. After using the HashMap.newHashMap method, the requested number of mappings can be added to the newly created HashMap without it being resized. There are similar new static factory methods for LinkedHashMap, WeakHashMap, HashSet, and LinkedHashSet. The complete set of new methods is:

• HashMap.newHashMap
• LinkedHashMap.newLinkedHashMap
• WeakHashMap.newWeakHashMap
• HashSet.newHashSet
• LinkedHashSet.newLinkedHashSet

The int-argument constructors for these classes set the "capacity" (internal table size) which is not the same as the number of elements that can be accommodated. The capacity is related to the number of elements by a simple but error-prone calculation. For this reason, programs should use these new static factory methods in preference to the int-argument constructors.

New Methods to Create Preallocated HashMaps and HashSets

New static factory methods have been introduced to allow creation of HashMap and related instances that are preallocated to accommodate an expected number of mappings or elements. After using the HashMap.newHashMap method, the requested number of mappings can be added to the newly created HashMap without it being resized. There are similar new static factory methods for LinkedHashMap, WeakHashMap, HashSet, and LinkedHashSet. The complete set of new methods is:

• HashMap.newHashMap
• LinkedHashMap.newLinkedHashMap
• WeakHashMap.newWeakHashMap
• HashSet.newHashSet
• LinkedHashSet.newLinkedHashSet

The int-argument constructors for these classes set the "capacity" (internal table size) which is not the same as the number of elements that can be accommodated. The capacity is related to the number of elements by a simple but error-prone calculation. For this reason, programs should use these new static factory methods in preference to the int-argument constructors.

Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName

The JDK implementation of X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames has been enhanced to additionally return the type-id and value fields of an otherName. The value field is returned as a String if it is encoded as a character string or otherwise as a byte array, which is helpful as it avoids having to parse the ASN.1 DER encoded form of the name.

PSSParameterSpec(int) Constructor and DEFAULT Static Constant Are Deprecated

It is recommended to construct PSSParameterSpec explicitly with all desired values instead of using the DEFAULT static constant or the single argument constructor which takes the salt length. Both use the default values in the initial version of the PKCS#1 standard and some of these values are no longer recommended due to advances in cryptanalysis.

RC2 and ARCFOUR Algorithms Added to jdk.security.legacyAlgorithms Security Property

The RC2 and ARCFOUR (RC4) algorithms have been added to the "jdk.security.legacyAlgorithms" security property in the java.security configuration file. The keytool tool issues warnings when a weak RC2 or ARCFOUR algorithm is used for its commands associated with secret key entries in the keystore.

DES, DESede and MD5 Algorithms Added to jdk.security.legacyAlgorithms Security Property

The DES, DESede and MD5 algorithms have been added to the "jdk.security.legacyAlgorithms" security property in the java.security configuration file. The keytool tool issues warnings when a weak DES or DESede algorithm is used for its commands associated with secret key entries in the keystore.

getParameters of ECDSA Signature Objects Always Return null

In order to be compliant to RFC 5758 Section 3.2, the Signature::getParameters method on an ECDSA signature object from the SunEC security provider will always return null, even if an earlier setParameter method has been called on this object.

Make Annotation toString Output for enum Constants Usable for Source Input

The exact toString format for annotations is not specified; however, the toString output is intended to be usable for source input. The toString output of enum constants was changed to two ways so that it would be usable as source input: * The name of the constant is used (rather than the output is its toString method) * For the name of the enum class, its canonical name rather than its binary name is used.

Additional Date-Time Formats

Additional date/time formats are now introduced in java.time.format.DateTimeFormatter/DateTimeFormatterBuilder classes. In prior releases, only 4 predefined styles, i.e., FormatStyle.FULL/LONG/MEDIUM/SHORT are available. Now the users can specify their own flexible style with this new DateTimeFormatter.ofLocalizedPattern(String requestedTemplate) method. For example, ` DateTimeFormatter.ofLocalizedPattern("yMMM") produces a formatter, which can format a date in a localized manner, such as "Feb 2022" in theUSlocale, while "2022年2月" in the Japanese locale. Supporting methodDateTimeFormatterBuilder.appendLocalized(String requestedTemplate)`is also provided.

Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate

Three chronologies in java.time.chrono package, namely JapaneseChronology, MinguoChronology, and ThaiBuddhistChronology now support ISO-based fields, such as IsoFields.QUARTER_OF_YEAR. These chronologies implement the new method, isIsoBased() which has been added in the java.time.chrono.Chronology interface. The boolean returned from this method indicates if the implementing chronology is ISO chronology based, which means it has the same year/month structure as IsoChronology.

Here is an example: ` JapaneseDate.now().getLong(IsoFields.QUARTER_OF_YEAR) will return the correct quarter-of-year value, which used to be throwing anUnsupportedTemporalTypeException` with prior JDK releases.

java.time.DateTimeFormatter: Wrong Definition of Symbol F

The definition and its implementation of the pattern symbol F in java.time.format.DateTimeFormatter/Builder has been modified. It was tied with ChronoField.ALIGNED_DAY_OF_WEEK_IN_MONTH field, which did not agree with java.text.SimpleDateFormat and Unicode Consortium's LDML. With this release, it represents ChronoField.ALIGNED_WEEK_OF_MONTH field. For example, the number 2 means "the 2nd Wednesday in July."

Deserialization Filter and Filter Factory Property Error Reporting Were Under Specified

Invalid values of the command line and the security properties of jdk.serialFilterand jdk.serialFilterFactory are reported by throwing java.lang.IllegalStateException on the first use. The property values are checked when constructing java.io.ObjectInputStream or when calling the methods of java.io.ObjectInputFilter.Config including getSerialFilter() and getSerialFilterFactory(). The IllegalStateException indicates that the serial filter or serial filter factory is invalid and cannot be used; deserialization is disabled. Previously, the exception thrown was ExceptionInInitializerError.

Add a -providerPath Option to jarsigner

A new option -providerPath has been added to jarsigner. One can use this option to specify the class path of an alternate keystore implementation. It can be used together with the -providerClass option.

Allow per-user and System Wide Configuration of a jpackaged app

jpackaged applications support both system-wide and per-user configuration.

jpackage application launcher will look up the corresponding .cfg file not only in the application installation directory (the system-wide installation location) but also in user-specific locations. User-specific directories for .cfg file look up are:

Linux ` ~/.local/${PACKAGE_NAME} ~/.${PACKAGE_NAME} macOS `` ~/Library/Application Support/${PACKAGE_NAME} ` Windows %LocalAppData%\%PACKAGE_NAME% %AppData%\%PACKAGE_NAME% `` where ${PACKAGE_NAME} and %PACKAGE_NAME% refer to jpackaged application name.

ForkJoinPool and ThreadPoolExecutor do not use Thread::start to Start Worker Threads

java.util.concurrent.ForkJoinPool and java.util.concurrent.ThreadPoolExecutor have changed in this release to not start worker threads with the Thread.start method. This may impact code that constructs a ForkJoinPool or ThreadPoolExecutor with a thread factory that creates worker Threads that override the no-arg start method. The overridden start method will not be invoked when worker threads are started. The change in behavior does not impact code that overrides the ForkJoinWorkerThread.onStart() method. The onStart() method will continue to be invoked by fork join worker threads when they start. A future release will re-examine the issue of thread factories creating threads that override the start method.

JVM TI Changes to Support Virtual Threads

The JVM Tool Interface (JVM TI) has been updated in this release to support virtual threads. Maintainers of agents that use JVM TI are strongly recommended to read JEP 425 and the JVM TI 19.0 specification. The following is a summary of the JVM TI support for virtual threads:

• Most JVM TI functions that are called with a jthread (i.e., a JNI reference to a Thread object) can be called with a reference to a virtual thread. The functions that are not supported on virtual threads are PopFrame, ForceEarlyReturn, StopThread, AgentStartFunction and GetThreadCpuTime. The SetLocal* functions support setting local variables in the top-most frame of virtual threads that are suspended at a breakpoint or single step event but are allowed to fail with JVMTI_ERROR_OPAQUE_FRAME in other scenarios.

• All JVM TI events, with the exception of those posted during early VM startup or during heap iteration, can have event callbacks invoked in the context of a virtual thread.

• The GetAllThreads and GetAllStackTraces functions are specified to return all platform threads rather than all threads.

• New functions SuspendAllVirtualThreads and ResumeAllVirtualThreads are added to support bulk suspend and resume of virtual threads. New events VirtualThreadStart and VirtualThreadEnd are added to support tracking of virtual threads. A new capability, can_support_virtual_threads is used to enable the use of the new functions and events.

Existing JVM TI agents will mostly work as before, but may encounter errors if they invoke functions that are not supported on virtual threads. These will arise when an agent that is unaware of virtual threads is used with an application that uses virtual threads. The change to GetAllThreads to return an array containing only the platform threads may be an issue for some agents. Existing agents that enable the ThreadStart and ThreadEnd events for all threads may encounter performance issues until they are upgraded to have finer control of these events.

Source and Binary Incompatible Changes to java.lang.Thread

The are a few source and binary incompatible changes that may impact code that extends java.lang.Thread.

• Thread defines several new methods in this release. If code in an existing source file extends Thread and a method in the subclass conflicts with any of the new Thread methods then the file will not compile without change.

• Thread.Builder is added as a nested interface. If code in an existing source file extends Thread, imports a class named Builder, and code in the subclass references "Builder" as a simple name, then the file will not compile without change.

• Thread.isVirtual(), Thread.threadId() and Thread.join(Duration) are added as final methods. If there is existing compiled code that extends Thread and the subclass declares a method with the same name, parameters, and return type as any of these methods then IncompatibleClassChangeError will be thrown at run-time if the subclass is loaded.

For further details, see the JEP 425, section java.lang.Thread.

java.lang.ThreadGroup Is degraded

Legacy java.lang.ThreadGroup has been degraded in this release. It is no longer possible to explicitly destroy a thread group. In its place, ThreadGroup is changed to no longer keep a strong reference to subgroups. A thread group is thus eligible to be GC'ed when there are no live threads in the group and nothing else is keeping the thread group alive.

The behavior of several methods, deprecated for removal in prior releases, are changed as follows:

• The destroy method does nothing.

• The isDestroyed method returns false.

• The setDaemon and isDaemon methods set/get a daemon status that is not used for anything.

• The suspend, resume, and stop methods throw UnsupportedOperationException.

For further details, see the JEP 425, section java.lang.ThreadGroup.

Thread Context ClassLoader Changed to be a Special Inheritable thread-local

The thread context ClassLoader is specified in this release to be a special inheritable thread-local. This change should be transparent to existing code with the exception of code that uses the 5-arg Thread constructor (added in Java 9) to create a Thread that does not inherit the initial values of inheritable thread-locals from the constructing thread. With this release, invoking the 5-arg Thread constructor with the parameter inheritInheritableThreadLocals set to false will create a Thread that does not inherit the initial value of the context ClassLoader from the constructing thread. The Thread.setContextClassLoader method may be used to change the context ClassLoader of the new thread if needed.

For further details, see the JEP 425, section Thread-local variables.

C2 Compilation Errors Unpredictably Crashes JVM

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

Support for PAC-RET Protection on Linux/AArch64

Support for PAC-RET protection on the Linux/AArch64 platform has been introduced.

When enabled, OpenJDK will use hardware features from the ARMv8.3 Pointer Authentication Code (PAC) extension to protect against Return Orientated Programming (ROP) attacks. For more information on the PAC extension see "Providing protection for complex software" or the "Pointer authentication in AArch64 state" section in the Arm ARM.

To take advantage of this feature, first OpenJDK must be built with the configuration flag --enable-branch-protection using GCC 9.1.0+ or LLVM 10+ . Then, the runtime flag -XX:UseBranchProtection=standard will enable PAC-RET protection if the system supports it and the java binary was compiled with branch-protection enabled; otherwise the flag is silently ignored. Alternatively, -XX:UseBranchProtection=pac-ret will also enable PAC-RET protection, but in this case if the system does not support it or the java binary was not compiled with branch-protection enabled, then a warning will be printed.

(D)TLS Signature Schemes

New Java SE APIs, javax.net.ssl.SSLParameters.getSignatureSchemes() and javax.net.ssl.SSLParameters.setSignatureSchemes(), have been added to allow applications to customize the signature schemes used in individual TLS or DTLS connections.

Note that the underlying provider may define the default signature schemes for each TLS or DTLS connection. Applications may also use the existing "jdk.tls.client.SignatureSchemes" and/or "jdk.tls.server.SignatureSchemes" system properties to customize the provider-specific default signature schemes. If not null, the signature schemes passed to the setSignatureSchemes() method will override the default signature schemes for the specified TLS or DTLS connections.

Note that a provider may not have been updated to support the new APIs and in that case may ignore the signature schemes that are set. The JDK SunJSSE provider supports this method. It is recommended that 3rd party providers add support for these methods when they add support for JDK 19 or later releases.

Change in SSLEngine.closeInbound() Behavior

The SunJSSE close notification checks for SSLEngine to have been made less strict to conform to changes in the Transport Layer Security (TLS) RFCs. See also JDK-8253368.

Specifically, if an application tries to close its SSLEngine inbound side using SSLEngine.closeInbound() without having received a close notification message from its peer, the SSLEngine will no longer:

1. trigger the transmission of a TLS fatal-level alert to the peer, and
2. invalidate the current TLS session.

The new behavior will still consider this condition an error and will throw a local javax.net.ssl.SSLException. But a fatal-level alert will no longer be generated to be sent to the peer, and the underlying session will remain valid.

In addition, the internal transport context for the SSLEngine will also now be closed. This may result in a different SSLEngineResult.HandshakeStatus value on the SSLEngine. Any outstanding outbound data must still be obtained (SSLEngine.wrap()) and sent in order to gracefully close the connection.

TLS Cipher Suites Using 3DES Removed From the Default Enabled List

The following TLS cipher suites that use the obsolete 3DES algorithm have been removed from the default list of enabled cipher suites:

• TLSECDHEECDSAWITH3DESEDECBC_SHA
• TLSECDHERSAWITH3DESEDECBC_SHA
• SSLDHERSAWITH3DESEDECBC_SHA
• SSLDHEDSSWITH3DESEDECBC_SHA
• TLSECDHECDSAWITH3DESEDECBC_SHA
• TLSECDHRSAWITH3DESEDECBC_SHA
• SSLRSAWITH3DESEDECBCSHA

Note that cipher suites using 3DES are already disabled by default in the jdk.tls.disabledAlgorithms security property. You may use these suites at your own risk by removing 3DESEDECBC from the jdk.tls.disabledAlgorithms security property and re-enabling the suites via the setEnabledCipherSuites() method of the SSLSocket, SSLServerSocket or SSLEngine classes. Alternatively, if an application is using the HttpsURLConnection class, the https.cipherSuites system property can be used to re-enable the suites.

Remove Finalizer Implementation in SSLSocketImpl

The finalizer implementation in SSLSocket has been removed, with the underlying native resource releases now done by the Socket implementation. With this update, the TLS close_notify messages will no longer be emitted if SSLSocket is not explicitly closed.

Not closing Sockets properly is an error condition that should be avoided. Applications should always close sockets and not rely on garbage collection.

Fully Support Endpoint Identification Algorithm in RFC 6125

The JDK SunJSSE provider implementation has been enhanced to be fully compliant with RFC 6125. Prior to this release, the implementation was compliant except for one case, which has now been addressed: the implementation will not attempt to match wildcard domains in TLS certificates where the wildcard character comprises a label other than the left-most label.

If necessary, applications can workaround this restriction by implementing their own HostnameVerifier or TrustManager.

New Options for ktab to Provide Non-Default Salt

Two new options are added to the ktab command when adding new keytab entries. When ktab -a username password -s altsalt is called, altsalt is used instead of the default salt. When ktab -a username password -f is called, the tool will contact the KDC to fetch the actual salt used.

Windows KeyStore Updated to Include Access to the Local Machine Location

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")

Use Larger Default key Sizes if not Explicitly Specified

JDK providers use provider-specific default values if the caller does not specify a key size when using a KeyPairGenerator or KeyGenerator object to generate a key pair or secret key. With this enhancement, the default key sizes for various crypto algorithms have been increased as follows: - RSA, RSASSA-PSS, DH: from 2048 to 3072 - EC: from 256 to 384 - AES: from 128 to 256 (if permitted by crypto policy), falls back to 128 otherwise.

In addition, the jarsigner tool will now use SHA-384 instead of SHA-256 as the default digest algorithm. The default signature algorithm for the jarsigner tool has also been adjusted accordingly. SHA-384 is used instead of SHA-256 except for longer key sizes whose security strength matches SHA-512. Note that for DSA keys, jarsigner will continue using SHA256withDSA as the default signature algorithm. This ensures maximum interoperability with older JDK releases. For more details, please refer to the keytool and jarsigner documentation.

OAEPParameterSpec.DEFAULT Static Constant Is Deprecated

It is recommended to construct OAEPParameterSpec explicitly with desired values instead of using the DEFAULT static constant. The DEFAULT static constant uses the default values in the initial version of the PKCS#1 standard and some of these values are no longer recommended due to advances in cryptanalysis.

FileChannel.transferFrom May Transfer Fewer Bytes Than Expected

The performance of FileChannel.transferFrom() has been improved significantly on Linux kernel version 4.5 and later for the case where the method is used to transfer bytes from one FileChannel to another. This change adds to the preexisting set of scenarios in which the number of bytes actually transferred might be less than the number requested to be transferred. That is to say, the value returned by transferFrom() can be less than the value of the count parameter: a “short transfer.” This is permitted by the specification, but might impact broken code that ignores the returned count and assumes it is always equal to count.

FileChannel.lock/tryLock Changed to Treat Size 0 to Mean the Locked Region Goes to end of File

The method java.nio.channels.FileChannel.lock(long position, long size, boolean shared) has been changed such that a size value of zero means to lock all bytes from the specified starting position to the end of the file, regardless of whether the file is subsequently extended or truncated.

Files.copy Copies POSIX Attributes to Target on Foreign File System

The method java.nio.file.Files.copy(Path,Path) has been changed to copy POSIX file attributes from the source file to the destination file when the two files are associated with different file system providers, for example copying a file from the default file system to a zip file system. Both the source and target file systems must support the POSIX file attribute view. The POSIX attributes copied are constrained to the file access permissions; owner and group owner of the file are not copied.

Regex \b Character Class now Matches ASCII Characters Only by Default

The \b metacharacter now matches ASCII word characters by default in the same way that the \w metacharacter does. For \b to match Unicode characters, the UNICODECHARACTERCLASS must be set in the same way that it would need to be set for \w to match Unicode characters.

Toolchain Upgrade to Visual Studio 2022

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. More information can be found in “C++ binary compatibility between Visual Studio versions”.

JavaDoc Search Enhancements

API documentation generated by JavaDoc now provides a standalone search page and the search syntax has been enhanced to allow for multiple search terms.

New System Property to Disable Windows Alternate Data Stream Support in java.io.File

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 Mark and Reset Methods of InputStream and FilterInputStream Are no Longer Synchronized

The synchronized keyword is removed from the mark and reset methods of java.io.InputStream and java.io.FilterInputStream. This keyword serves no purpose as the other methods in these classes do not synchronize.

Removal of Diagnostic Flag GCParallelVerificationEnabled

The diagnostic flag GCParallelVerificationEnabled has been removed.

There are no known advantages of disabling parallel heap verification, so this flag has never been used except with its default value. This default value enabled multi-threaded verification for a very long time with no issues. Single-threaded heap verification would even be much slower than verification already is.