Java JDK 22 (64-bit)

What's new in this version:

Major New Functionality:
Language:
- Unnamed Variables & Patterns
- Enhance the Java programming language with unnamed variables and unnamed patterns, which can be used when variable declarations or nested patterns are required but never used. Both are denoted by the underscore character, _.

Language Previews:
Statements before super(...) (Preview):
- In constructors in the Java programming language, allow statements that do not reference the instance being created to appear before an explicit constructor invocation. This is a preview language feature.

Stream Gatherers (Preview):
- Enhance the Stream API to support custom intermediate operations. This will allow stream pipelines to transform data in ways that are not easily achievable with the existing built-in intermediate operations. This is a preview API.

String Templates (Second Preview):
- Enhance the Java programming language with string templates. String templates complement Java's existing string literals and text blocks by coupling literal text with embedded expressions and template processors to produce specialized results. This is a preview language feature and API.

Implicitly Declared Classes and Instance Main Methods (Second Preview):
- Evolve the Java programming language so that students can write their first programs without needing to understand language features designed for large programs. Far from using a separate dialect of the language, students can write streamlined declarations for single-class programs and then seamlessly expand their programs to use more advanced features as their skills grow. This is a preview language feature.

Libraries:
Foreign Function & Memory API:
- Introduce an API by which Java programs can interoperate with code and data outside of the Java runtime. By efficiently invoking foreign functions (i.e., code outside the JVM), and by safely accessing foreign memory (i.e., memory not managed by the JVM), the API enables Java programs to call native libraries and process native data without the brittleness and danger of JNI.

Library Previews and Incubator:
Class-File API (Preview):
- Provide a standard API for parsing, generating, and transforming Java class files. This is a preview API.

Structured Concurrency (Second Preview):
- Simplify concurrent programming by introducing an API for structured concurrency. Structured concurrency treats groups of related tasks running in different threads as a single unit of work, thereby streamlining error handling and cancellation, improving reliability, and enhancing observability. This is a preview API.

Scoped Values (Second Preview):
- Introduce scoped values, which enable managed sharing of immutable data both with child frames in the same thread, and with child threads. Scoped values are easier to reason about than thread-local variables and have lower space and time costs, especially when used in combination with Virtual Threads and Structured Concurrency. This is a preview API.

Vector API (Seventh Incubator):
- Introduce an API to express vector computations that reliably compile at runtime to optimal vector instructions on supported CPU architectures, thus achieving performance superior to equivalent scalar computations.

Performance:
Region Pinning for G1:
- Reduce latency by implementing region pinning in G1, so that garbage collection need not be disabled during Java Native Interface (JNI) critical regions.
- See below for additional information

Tooling:
Launch Multi-File Source-Code Programs:
- Enhance the java application launcher to be able to run a program supplied as multiple files of Java source code. This will make the transition from small programs to larger ones more gradual, enabling developers to choose whether and when to go to the trouble of configuring a build tool.

New Features:
- This section describes some of the enhancements in Java SE 22 and JDK 22. In some cases, the descriptions provide links to additional detailed information about an issue or a change. The APIs described here are provided with the Oracle JDK. It includes a complete implementation of the Java SE 22 Platform and additional Java APIs to support developing, debugging, and monitoring Java applications. Another source of information about important enhancements and new features in Java SE 22 and JDK 22 is the Java SE 22 (JSR 397) Platform Specification, which documents the changes to the specification made between Java SE 21 and Java SE 22. This document includes descriptions of those new features and enhancements that are also changes to the specification. The descriptions also identify potential compatibility issues that you might encounter when migrating to JDK 22.

core-libs/java.lang:
- Support Unicode 15.1

This release upgrades the Unicode version to 15.1, which includes updated versions of the Unicode Character Database and 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.

core-libs/java.lang.foreign:
- Foreign Function & Memory API (JEP 454)
- The Foreign Function & Memory API allows Java programs to interoperate with code and data outside of the Java runtime
- Access to foreign memory is realized via the MemorySegment class. A memory segment is backed by a contiguous region of memory, located either off-heap or on-heap. Safe and deterministic deallocation of off-heap memory segments is provided via the Arena class. Structured access to memory segments is realized via the MemoryLayout class. A memory layout can be used to compute the size and offsets of struct fields, and to obtain var handles that read and write the data in memory segments.
- Access to foreign functions is realized via the Linker class. The native linker can be used to obtain method handles that provide a fast way for Java code to invoke native code. Native code is invoked using the calling convention for the OS and processor where the Java runtime is executing, so Java code is not polluted with platform-specific details. Native code can also call back into Java code.
- Native code is generally unsafe; if used incorrectly, it might crash the JVM or result in memory corruption. Some of the methods in the Foreign Function & Memory API are considered unsafe because they provide access to native code. These unsafe methods are restricted, which means their use is permitted but causes warnings at run time. Developers can compile their code with -Xlint:restricted to learn if it will produce warnings at run time due to use of unsafe methods.
- If the risks associated with native code are understood, then unsafe methods can be used without warnings at run time by passing --enable-native-access=... on the java command line. For example, java --enable-native-access=com.example.myapp,ALL-UNNAMED ... enables warning-free use of unsafe methods by code in the com.example.myapp module and code on the class path (denoted by ALL-UNNAMED). Additionally, in an executable JAR, the manifest attribute Enable-Native-Access: ALL-UNNAMED enables warning-free use of unsafe methods by code on the class path; no other module can be specified. When the --enable-native-access option or JAR manifest attribute is present, any use of unsafe methods by code outside the list of specified modules causes an IllegalCallerException to be thrown, rather than a warning to be issued.

core-libs/java.net:
- TCP_KEEPxxxx Extended Socket Options Are Now Supported on the Windows Platform
- The java.net.ExtendedSocketOptions TCP_KEEPIDLE and TCP_KEEPINTERVAL are supported on Windows platforms starting from Windows 10 version 1709 and onwards. TCP_KEEPCOUNT is supported starting from Windows 10 version 1703 and onwards.

core-libs/java.nio.charsets:
- New Constants for 32-bit UTF Charsets

The following three new constants in java.nio.charset.StandardCharsets class have been introduced:
- UTF_32
- UTF_32BE
- UTF_32LE
- These are 32-bit based UTF charsets that are in parallel with the existing 8-bit and 16-bit equivalents.

core-libs/java.text:
- 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"))
- Besides the default concatenation type STANDARD (= and), the class provides two additional types, OR for "or" concatenation, and UNIT for concatenation suitable for units for the locale.

core-libs/java.util:
- Add equiDoubles() Method to java.util.random.RandomGenerator
- A new method, equiDoubles(), has been added to java.util.random.RandomGenerator.
- equiDoubles() guarantees a uniform distribution, provided the underlying nextLong(long) method returns uniformly distributed values, that is as dense as possible. It returns a DoubleStream rather than individual doubles because of slightly expensive initial computations. They are better absorbed as setup costs for the stream rather than being repeated for each new computed value.
- The aim is to overcome some numerical limitations in the families of doubles() and nextDouble() methods. In these, an affine transform is applied to a uniformly distributed pseudo-random value in the half-open interval [0.0, 1.0) to obtain a pseudo-random value in the half-open interval [origin, bound). However, due to the nature of floating-point arithmetic, the affine transform ends up in a slightly distorted distribution, which is not necessarily uniform.

hotspot/gc:
G1: Fast Collection of Evacuation Failed Regions
- G1 now reclaims regions that failed evacuation in the next garbage collection.
- When there is not enough space to move Java objects from the collection set, young generation regions for example, to some destination area, or that region has been pinned and contains non-movable Java objects (see [JEP 423]), G1 considers that region to have failed evacuation.
- Previously, such regions were moved into the old generation as completely full regions, and left lingering for re-examination until the next complete heap analysis, marking, found them to be reclaimable in the next space reclamation phase. Very often, such regions are sparsely populated because only a very few objects were not relocatable or very few objects were actually pinned.
- With this change, G1 considers evacuation failed regions as reclaimable beginning with any subsequent garbage collection. If the pause time permits, G1 will evacuate them in addition to the existing collection set.
- This can substantially reduce the time to reclaim these mostly empty regions, decreasing heap pressure and the need for garbage collection activity in the presence of evacuation failed regions.

hotspot/gc:
Parallel: Precise Parallel Scanning of Large Object Arrays for Young Collection Roots
- During young collection, ParallelGC partitions the old generation in 64kB stripes when scanning it for references into the young generation. These stripes are assigned to worker threads that do the scanning in parallel as work units.
- Before this change Parallel GC always scanned these stripes completely even if only a small part had been known to contain interesting references. Additionally every worker thread processed the objects that start in that stripe by itself including any part of objects that extend into other stripes. This behavior limited parallelism when processing large objects: a single large object potentially containing thousands of references had been scanned by a single thread only and in full, and would also cause bad scaling due to memory sharing and cache misses in the subsequent long work stealing phase.
- With this change, Parallel GC workers limit work to their stripe, and only process interesting parts of large object arrays. This reduces work done by a single thread for a stripe, improves parallelism and reduces the amount of work stealing. Parallel GC pauses is now on par with G1 in presence of large object arrays, reducing pause times by 4-5 times in some cases.

hotspot/gc:
- Region Pinning for G1 (JEP 423)
- This JEP reduces latency by implementing region pinning in G1, so that garbage collection need not be disabled during Java Native Interface (JNI) critical regions.
- Java threads that use native code do not stall garbage collections any more. Garbage collections will execute regardless of native code keeping references to Java objects. The garbage collection will keep objects that may be accessed by native code in place, collecting garbage only in surrounding heap areas but will be otherwise unaffected.

hotspot/gc:
Parallel: Better GC Throughput with Large Object Arrays
- During a young collection, Parallel GC searches for dirty cards in the card table to locate old-to-young pointers. After finding dirty cards, Parallel GC uses the internal bookkeeping data structures to locate object starts for heap-parsing to be able to walk the heap within these dirty cards object-by-object.
- This change modifies the internal bookkeeping data structure to the one used by Serial and G1. As a result, the object start lookup time is improved and one can observe about a 20% reduction of Young-GC pause in some benchmarks using large object arrays.

hotspot/gc:
Serial: Better GC Throughput with Scarce Dirty Cards
- During a young collection, Serial GC searches for dirty cards in the card table to locate old-to-young pointers. After finding dirty cards, Serial GC uses the block offset table to locate object starts for heap-parsing to be able to walk the heap within these dirty cards object-by-object.
- This change improves the object start lookup and search for dirty cards resulting in a large (~40%) reduction in Young-GC pause in some benchmarks using large object arrays.

hotspot/gc:
G1: Balance Code Root Scan Phase during Garbage Collection
- The Code Root Scan Phase during garbage collection finds references to Java objects in compiled code. To speed up this process, G1 maintains a remembered set for compiled code that contains references into the Java heap. That is, every region contains a set of compiled code that contains references into it.
- Assuming that such references are few, previous code used a single thread per region to iterate over a particular region's references, which poses a scalability bottleneck if the distribution of these references is very unbalanced.
- G1 now distributes this code root scan work across multiple threads within regions, removing this bottleneck.

security-libs/java.security:
- 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.

security-libs/javax.security:
HSS/LMS: keytool and jarsigner Changes
- The jarsigner and keytool tools have been updated to support the Hierarchical Signature System/Leighton-Micali Signature (HSS/LMS) signature algorithm. jarsigner supports signing JAR files with HSS/LMS and verifying JAR files signed with HSS/LMS while keytool supports generating HSS/LMS key pairs.
- The JDK includes a security provider that supports HSS/LMS signature verification only. In order to use the key pair generation and signing features of keytool and jarsigner, a third-party provider that supports HSS/LMS key pair and signature generation and a keystore implementation that can store HSS/LMS keys is required.
- Even though there’s no specific Java SE API to initialize an HSS/LMS key pair generator, keytool can function with a third-party KeyPairGenerator implementation that supports initialization via an integer keysize or a NamedParameterSpec object. In such cases, users are able to provide the parameters using the existing -keysize or -groupname options of keytool.
- As part of this change, the JAR specification was modified to repurpose the existing “.DSA” extension for JAR files signed with HSS/LMS and other forthcoming signature algorithms.

security-libs/javax.xml.crypto:
- Update XML Security for Java to 3.0.3

The XML Signature implementation has been updated to Santuario 3.0.3. Support for four new SHA-3 based RSA-MGF1 SignatureMethod algorithms have been added: SignatureMethod.SHA3_224_RSA_MGF1, SignatureMethod.SHA3_256_RSA_MGF1, SignatureMethod.SHA3_384_RSA_MGF1, and SignatureMethod.SHA3_512_RSA_MGF1.

tools/javadoc(tool):
- The inheritDoc Tag and Method Comments Algorithm Have Been Changed
- An optional parameter has been added to the inheritDoc tag so that an author can specify the supertype from which to search for inherited documentation. Additionally, the algorithm to search for inherited documentation has been modified to better align with the method inheriting and overriding rules in Java Language Specification.

For more details, see the following sections of the Documentation Comment Specification for the Standard Doclet:
- Method Documentation
- {@inheritDoc}

xml/jaxp:
- Add a Built-in Catalog to JDK XML Module
- A JDK built-in catalog is introduced to host DTDs defined by the Java Platform. The JDK creates a CatalogResolver based on the built-in catalog when needed to function as the default external resource resolver. When no user-defined resolvers are registered, a JDK XML processor will fall back to the default CatalogResolver and will attempt to resolve an external reference before making a connection to fetch it. The fall-back also takes place if a user-defined resolver exists but allows the process to continue when unable to resolve the resource.
- If the default CatalogResolver is unable to locate a resource, it will signal the XML processors to continue processing, or skip the resource, or throw a CatalogException. The action it takes is configured with the jdk.xml.jdkcatalog.resolve property. 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.
- For further information, see the JDK built-in Catalog section of the java.xml module summary.

xml/jaxp:
- 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: , 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.

hotspot/jfr:
- JFR Event for @Deprecated Methods
- A new JFR event, jdk.DeprecatedInvocation, has been added to JDK 22 to help users detect their use of deprecated methods located in the JDK.
- To record these events in JFR, a user must specify a recording on the command line, like -XX:StartFlightRecording. Starting a recording during runtime, for example, using jcmd or the JFR Java API, will not have these events reported unless -XX:StartFlightRecording is specified on the command line.
- The current design will only report direct method invocations where the caller resides outside the JDK. Intra-JDK invocations will not be reported. Additionally, invoking methods declared deprecated but located outside of the JDK, for example in a third-party library, will not be reported, at least not during this first implementation. This might change in the future.
- There exists a small restriction in the reporting of invocations from the Interpreter. In the situation where two caller methods are members of the same class, and they invoke the same deprecated method
- In this situation, only <InterpreterRestriction.invoke1, System.getSecurityManager> will be reported because the Interpreter implementation will consider System.getSecurityManager() to be resolved and linked after the first call. When invoke2() is called, no slow path will be taken for the resolution of the System.getSecurityManager() method because it is already resolved as part of the cpCache. This restriction does not exist in C1 or C2, only in the Interpreter.
- When analyzing the reported events, checking all methods in the reported class is recommended. This slight restriction can be resolved using an iterative process; if one call site is fixed, the other will be reported in the next run.

Removed Features and Options:
- This section describes the APIs, features, and options that were removed in Java SE 22 and JDK 22. The APIs described here are those that are provided with the Oracle JDK. It includes a complete implementation of the Java SE 22 Platform and additional Java APIs to support developing, debugging, and monitoring Java applications. Another source of information about important enhancements and new features in Java SE 22 and JDK 22 is the Java SE 22 (JSR 397) Platform Specification, which documents changes to the specification made between Java SE 21 and Java SE 22. This document includes the identification of removed APIs and features not described here. The descriptions below might also identify potential compatibility issues that you could encounter when migrating to JDK 22. See CSRs Approved for JDK 22 for the list of CSRs closed in JDK 22.

core-libs:
- 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.

core-libs/java.lang:
- 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.

core-libs/java.lang:reflect:
- 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.

core-svc/tools:
- 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.

Deprecated Features and Options:
Additional sources of information about the APIs, features, and options deprecated in Java SE 22 and JDK 22 include:
- The Deprecated API page identifies all deprecated APIs including those deprecated in Java SE 22.
- The Java SE 22 (JSR 397) specification documents changes to the specification made between Java SE 21 and Java SE 22 that include the identification of deprecated APIs and features not described here.
- JEP 277: Enhanced Deprecation provides a detailed description of the deprecation policy. You should be aware of the updated policy described in this document.
- You should be aware of the contents in those documents as well as the items described in this release notes page.
- The descriptions of deprecated APIs might include references to the deprecation warnings of forRemoval=true and forRemoval=false. The forRemoval=true text indicates that a deprecated API might be removed from the next major release. The forRemoval=false text indicates that a deprecated API is not expected to be removed from the next major release but might be removed in some later release.
- The descriptions below also identify potential compatibility issues that you might encounter when migrating to JDK 22. See CSRs Approved for JDK 22 for the list of CSRs closed in JDK 22.

core-libs:
- sun.misc.Unsafe park, unpark, getLoadAverage, and 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).

hotspot/runtime:
- -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.
- Any existing code which uses this option should be updated to remove reference to this option.

security-libs/java.security:
- Deprecation of the jdk.crypto.ec Module
- The jdk.crypto.ec module is being deprecated with the intent to remove it. An empty module exists as a transition for developers to fix applications or jlink commands with hard-coded dependencies before removal. The SunEC JCE Provider, which provides Elliptic Curve Cryptography, is now in the java.base module. There should be no difference in cryptographic functionality with this deprecation.

tools/launcher:
- -Xdebug and -debug Options Are Deprecated for Removal
- The -Xdebug and -debug options of the java command have been deprecated for removal. These options have been ignored for several releases and don't provide any functionality. Using either of these options while launching java will now log a deprecation warning.
- Existing applications which use either of these options should be updated to remove references to these options.

Notable Issues Resolved:
- The following notes describe previous known issues or limitations that have been corrected in this release.

core-libs/java.lang.invoke:
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.

core-libs/java.lang.invoke:
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.

core-libs/java.time:
- Gregorian Era Names with java.time.format APIs
- Names for Gregorian eras returned from java.time.format APIs are now correctly retrieved from the CLDR locale data. Prior to this change, these APIs incorrectly used names from the legacy COMPAT locale data. For example, the Gregorian era names "BCE"/"CE" are now returned for the ROOT locale, instead of "BC"/"AD" that are in the COMPAT locale data. For possible compatibility issues and workarounds, refer to JDK-8320431 for more details.

hotspot/gc:
G1: More Deterministic Heap Resize at Remark
- During the Remark pause G1 adjusts the Java heap size to keep a minimum and maximum amount of free regions as set via the -XX:MinHeapFreeRatio and -XX:MaxHeapFreeRatio options.
- Before this change, G1 considered Eden regions as occupied (full) for this calculation. This makes heap sizing very dependent on current Eden occupancy, although after the next garbage collection these regions will be empty. With this change, Eden regions are considered as empty (free) for matters of Java heap sizing. This new policy also aligns Java heap sizing to full GC heap sizing.
- The effect is that G1 now expands the Java heap less aggressively and more deterministically, with corresponding memory savings but potentially executing more garbage collections.

tools/javac:
- ExecutableElement.getReceiverType and ExecutableType.getReceiverType() Changed to Return Annotated Receiver Types for Methods Loaded from Bytecode
- The implementation of ExecutableElement.getReceiverType and ExecutableType.getReceiverType now returns a receiver type for methods loaded from bytecode if the type has associated type annotations. Previously, it returned NOTYPE for all methods loaded from bytecode, which prevented associated type annotations from being retrieved.

tools/javac:
- TypeMirror Changed to Provide Annotations for Types Loaded from Bytecode
- The implementation of TypeMirror now provides access to annotations for types loaded from bytecode. Previously type annotations were not associated with types loaded from bytecode.
- Annotation processors can access type annotations for elements using AnnotationMirror#getAnnotationMirrors, and the annotations will be included in the output of AnnotationMirror#toString.
- Any programs that relied on annotations being omitted for elements loaded from the classpath should be updated to handle type annotations.

tools/javac:
- The javac Compiler Should Not Accept Private Method References with a Type Variable Receiver
- Prior to JDK 22, the javac compiler was accepting private method references with a type variable receiver.