RELEASE NOTES: JDK 22

`javac` Message If Implicit Annotation Processors Are Being Used

Annotation processing by javac is enabled by default, including when no annotation processing configuration options are present. Implicit annotation processing by default may be disabled in a future release, possibly as early as JDK 22. To alert javac users of this possibility, in JDK 21 javac prints a note if implicit annotation processing is being used. The text of the note is:

` Annotation processing is enabled because one or more processors were found on the class path. A future release of javac may disable annotation processing unless at least one processor is specified by name (-processor), or a search path is specified (--processor-path, --processor-module-path), or annotation processing is enabled explicitly (-proc:only, -proc:full). Use -Xlint:-options to suppress this message. Use -proc:none to disable annotation processing. `

Good build hygiene includes explicitly configuring annotation processing. To ease the transition to a different default policy in the future, the new-in-JDK-21 -proc:full javac option requests the current default behavior of looking for annotation processors on the class path.

Support Unicode 15.1

This release upgrades the Unicode version to 15.1, which includes updated versions of the Unicode Character Database, Unicode Standard Annexes #9, #15, and #29: The java.lang.Character class supports the Unicode Character Database, which adds 627 characters, for a total of 149,813 characters. The addition includes one new UnicodeBlock, which consists of urgently needed CJK ideographs, synchronized with planned additions to the Chinese national standard, GB 18030. The java.text.Bidi and java.text.Normalizer classes support Unicode Standard Annexes, #9 and #15, respectively. The java.util.regex package supports Extended Grapheme Clusters based on the Unicode Standard Annex #29. For more details about Unicode 15.1, refer to the Unicode Consortium’s release note.

Thread.countStackFrames has been removed

The method java.lang.Thread.countStackFrames() has been removed in this release. This method dates from JDK 1.0 as an API for counting the stack frames of a suspended thread. The method was deprecated in JDK 1.2 (1998), deprecated for removal in Java 9, and re-specified/degraded in Java 14 to throw UnsupportedOperationException unconditionally.

java.lang.StackWalker was added in Java 9 as a modern API for walking the current thread's stack.

-XshowSettings launcher behavior changes

The -XshowSettings:all and -XshowSettings launch options now differ in behavior. -XshowSettings will print a summary view for the locale and security categories and all information for the other categories. -XshowSettings:all will continue to print all settings information available.

The -XshowSettings launcher option will now reject bad values passed to it. In such cases, an error message is printed and the JVM launch is aborted. See java -X for valid options that can be used with the -XshowSettings option.

Available locales information now listed with -XshowSettings:locale option

The showSettings launcher option no longer prints available locales information by default, when -XshowSettings is used. The -XshowSettings:locale option will continue to print all settings related to available locales.

JVM May Hang When Using Generational ZGC if a VM Handshake Stalls on Memory

The JVM can hang under an uncommon condition that involves the JVM running out of heap memory, the GC just starting a relocation phase to reclaim memory, and a JVM thread-local Handshake asking to relocate an object.

-Xnoagent option is deprecated for removal

The -Xnoagent option of the java command has been deprecated for removal. This option has been ignored for many releases and doesn't provide any functionality. It will now generate a deprecation warning when used while launching java:

` OpenJDK 64-Bit Server VM warning: Option -Xnoagent was deprecated in JDK 22 and will likely be removed in a future release. `

Any existing code which uses this option should be updated to remove reference to this option.

New Security Category for `-XshowSettings` Launcher Option

The -XshowSettings launcher has a new security category. Settings from security properties, security providers and TLS related settings are displayed with this option. A security sub-category can be passed as an argument to the security category option. See the output from java -X:

` -XshowSettings:security show all security settings and continue -XshowSettings:security:*sub-category* show settings for the specified security sub-category and continue. Possible *sub-category* arguments for this option include: all: show all security settings and continue properties: show security properties and continue providers: show static security provider settings and continue tls: show TLS related security settings and continue `

Third party security provider details will be reported if they are included in the application class path or module path and such providers are configured in the java.security file.

Removed SECOM Trust System's RootCA1 Root Certificate

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

```

Added Certigna Root CA Certificate

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 `

Increase Default Value of the System Property `jdk.jar.maxSignatureFileSize`

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 old core reflection implementation has been removed

The new core reflection implementation has been the default since JDK 18 and the old implementation is now removed. The -Djdk.reflect.useDirectMethodHandle=false introduced by JEP 416 to enable the old core reflection implementation becomes a no-op.

Add a JDK Property for Specifying DTD Support

A new property jdk.xml.dtd.support is introduced that determines how XML processors handle DTDs. The new property can be set on factory APIs, as a Java system property, or in the JAXP Configuration File. The new property affects all XML processors uniformly.

The new property complements the two existing DTD properties: disallow-doctype-decl (fully qualified name: http://apache.org/xml/features/disallow-doctype-decl), which is applicable only to the DOM and SAX processors, and supportDTD (javax.xml.stream.supportDTD), which is applicable only to the StAX processor. When one of these existing properties is set on the respective processor factory, its value will take precedence over any value specified for the jdk.xml.dtd.support property.

For further information, see the Configuration section of the java.xml module summary.

Jdeps -profile and -P Option Have Been Removed

Compact profiles became obsolete in Java SE 9 when modules were introduced. The jdeps -profile and -P options were deprecated for removal in JDK 21 and now removed in JDK 22. Customers can use jdeps to find the set of modules required by their applications instead.

MethodHandles.Lookup::findStaticVarHandle Does Not Eagerly Initialize the Field's Declaring Class

In the previous releases, MethodHandles.Lookup::findStaticVarHandle eagerly initializes the declaring class of the static field when the VarHandle is created. As specified in the specification, the declaring class should be initialized when the VarHandle is operated on if it has not already been initialized. This issue is fixed in this release. The declaring class is no longer eagerly initialized when MethodHandles.Lookup::findStaticVarHandle is called. Existing code that relies on the previous behavior may observe a change of the order of the classes being initialized.

Reimplement MethodHandleProxies::asInterfaceInstance

In previous releases MethodHandleProxies::asInterfaceInstance returns a Proxy instance. MethodHandleProxies::asInterfaceInstance has been reimplemented to return instances of a hidden class that can be unloaded when all instances returned for the same interface becomes unreachable. Once unloaded, subsequent call to MethodHandleProxies::asInterfaceInstance will spin and define a new hidden class that may incur performance overhead.

sun.misc.Unsafe park/unpark, getLoadAverage, xxxFence methods are deprecated, for removal

The park, unpark, getLoadAverage, loadFence, storeFence, and fullFence methods defined by sun.misc.Unsafe have been deprecated for removal.

Code using these methods should move to java.util.concurrent.LockSupport.park/unpark (Java 5), java.lang.management.OperatingSystemMXBean.getSystemLoadAverage (Java 6), and java.lang.invoke.VarHandle.xxxFence (Java 9).

sun.misc.Unsafe shouldBeInitialized and ensureClassInitialized are removed

The shouldBeInitialized(Class) and ensureClassInitialized(Class) methods have been removed from sun.misc.Unsafe. These methods have been deprecated for removal since JDK 15. java.lang.invoke.MethodHandles.Lookup.ensureInitialized(Class) was added in Java 15 as a standard API to ensure that an accessible class is initialized.

Locale-Dependent List Patterns

A new class, ListFormat, which processes the locale-dependent list patterns has been introduced, based on Unicode Consortium's LDML specification. For example, a list of three Strings: "Foo", "Bar", "Baz" is typically formatted as "Foo, Bar, and Baz" in US English, while in French it is "Foo, Bar et Baz." The following code snippet does such formatting: ` ListFormat.getInstance().format(List.of("Foo", "Bar", "Baz")) The punctuation and/or the connecting words can be , such as "and"/"or", can be specified Besides the default concatenation typeSTANDARD(= and), the class provides two additional types,ORfor "or" concatenation, andUNIT` for concatenation suitable for units for the locale.

Validations on ZIP64 Extra Fields

A (JDK enhancement)[https://bugs.openjdk.org/browse/JDK-8311940] has improved validation of the ZIP64 Extra Fields contained within zip files and jar files. Files which do not satisfy these new validation checks may result in ZipException : Invalid CEN header (invalid zip64 extra data field size).

The following third party tools have released patches to better adhere to the ZIP File Format Specification: - Apache Commons Compress fix for Empty CEN Zip64 Extra Headers fixed in Commons Compress release 1.11 - Apache Ant fix for Empty CEN Zip64 Extra Headers fixed in Ant 1.10.14
- BND issue with writing invalid Extra Headers fixed in BND 5.3 - The maven-bundle-plugin 5.1.5 includes the BND 5.3 patch.

If these improved validation checks cause issues for deployed zip or jar files, check how the file was created and whether patches are available from the generating software to resolve the issue. The new validation checks can be disabled by adding -Djdk.util.zip.disableZip64ExtraFieldValidation=true to the runtime launcher arguments.

Further modification of validations on ZIP64 Extra Fields contained within zip and jar files will be made in the upcoming JDK release. See JDK-8313765.

JVM May Crash or Malfunction When Using ZGC and Non-Default ObjectAlignmentInBytes

Running the JVM with -XX:+UseZGC and non-default value of -XX:ObjectAlignmentInBytes may lead to JVM crashes or incorrect execution. The issue is caused by an incorrect JIT compiler optimization of the java.lang.Object.clone() method for this configuration. If using ZGC with a non-default value of ObjectAlignmentInBytes is desired, JIT compilation of java.lang.Object.clone() can be disabled using the command-line options -XX:+UnlockDiagnosticVMOptions -XX:DisableIntrinsic=_clone.

Unify Syntax of CompileOnly and CompileCommand

-XX:CompileOnly=pattern1,[...],patternN is now an alias for -XX:CompileCommand=compileonly,pattern1 [...] -XX:CompileCommand=compileonly,patternN

Exit VM for CompileCommand Parsing Errors

-XX:CompileCommand=... will now exit the VM with a non-zero exit code after a parsing error occurred.

`java.util.regex.MatchResult` Might Throw `StringIndexOutOfBoundsException` on Regex Patterns Containing Lookaheads and Lookbehinds

JDK-8132995 introduced an unintended regression when using instances returned by java.util.regex.Matcher.toMatchResult().

This happens on java.util.regex.Patterns containing lookaheads and lookbehinds that, in turn, contain groups. If these are located outside the match, it results in throwing StringIndexOutOfBoundsException when accessing these groups. See JDK-8312976 for an example.

JLine As The Default Console Provider

System.console() has changed in this release to return a Console with enhanced editing features that improve the experience of programs that use the Console API. In addition, System.console() now returns a Console object when the standard streams are redirected or connected to a virtual terminal. In prior releases, System.console() returned null for these cases. This change may impact code that uses the return from System.console() to test if the VM is connected to a terminal. If needed, running with -Djdk.console=java.base will restore older behavior where the console is only returned when it is connected to a terminal.

A new method Console.isTerminal() has been added to test if console is connected to a terminal.