Java Development Kit for Mac

What's new in this version:

Major New Functionality:
Language:
Primitive Types in Patterns, instanceof, and switch (Third Preview):
- Enhance pattern matching by allowing primitive types in all pattern contexts, and extend instanceof and switch to work with all primitive types. This is a preview language feature.

Module Import Declarations:
- Enhance the Java programming language with the ability to succinctly import all of the packages exported by a module. This simplifies the reuse of modular libraries, but does not require the importing code to be in a module itself.

Compact Source Files and Instance Main Methods:
- Evolve the Java programming language so that beginners can write their first programs without needing to understand language features designed for large programs. Far from using a separate dialect of the language, beginners can write streamlined declarations for single-class programs and then seamlessly expand their programs to use more advanced features as their skills grow. Experienced developers can likewise enjoy writing small programs succinctly, without the need for constructs intended for programming in the large.

Flexible Constructor Bodies:
- In the body of a constructor, allow statements to appear before an explicit constructor invocation, i.e., super(...) or this(...). Such statements cannot reference the object under construction, but they can initialize its fields and perform other safe computations. This change allows many constructors to be expressed more naturally. It also allows fields to be initialized before they become visible to other code in the class, such as methods called from a superclass constructor, thereby improving safety.

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

Scoped Values:
Stable Values (Preview):
- Introduce an API for stable values, which are objects that hold immutable data. Stable values are treated as constants by the JVM, enabling the same performance optimizations that are enabled by declaring a field final. Compared to final fields, however, stable values offer greater flexibility as to the timing of their initialization. This is a preview API.
- Vector API (Tenth Incubator):
- Introduce an API to express vector computations that reliably compile at runtime to optimal vector instructions on supported CPUs, thus achieving performance superior to equivalent scalar computations.

Security Libraries:
PEM Encodings of Cryptographic Objects (Preview):
- Introduce an API for encoding objects that represent cryptographic keys, certificates, and certificate revocation lists into the widely-used Privacy-Enhanced Mail (PEM) transport format, and for decoding from that format back into objects. This is a preview API.

Key Derivation Function API:
- Introduce an API for Key Derivation Functions (KDFs), which are cryptographic algorithms for deriving additional keys from a secret key and other data.

Performance:
Compact Object Headers:
- Change compact object headers from an experimental feature to a product feature.

Ahead-of-Time Command-Line Ergonomics:
- Make it easier to create ahead-of-time caches, which accelerate the startup of Java applications, by simplifying the commands required for common use cases.

Ahead-of-Time Method Profiling:
- Improve warmup time by making method-execution profiles from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. This will enable the JIT compiler to generate native code immediately upon application startup, rather than having to wait for profiles to be collected.

Monitoring:
JFR CPU-Time Profiling (Experimental):
- Enhance the JDK Flight Recorder (JFR) to capture more accurate CPU-time profiling information on Linux. This is an experimental feature.

JFR Cooperative Sampling:
- Improve the stability of the JDK Flight Recorder (JFR) when it asynchronously samples Java thread stacks. Achieve this by walking call stacks only at safepoints, while minimizing safepoint bias.
- JFR Method Timing & Tracing:
- Extend the JDK Flight Recorder (JFR) with facilities for method timing and tracing via bytecode instrumentation.

Removed Features and Options:
Removal of Experimental Feature - Graal JIT:
- The optional experimental Graal JIT compiler has been removed

New Features:
- This section describes some of the enhancements in Java SE 25 and JDK 25. 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 25 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 25 and JDK 25 is the Java SE 25 ( JSR 400) Platform Specification, which documents the changes to the specification made between Java SE 24 and Java SE 25. 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 25.

core-libs/java.lang New getChars(int, int, char[], int) Method in CharSequence and CharBuffer (JDK-8343110):
- A new method, getChars(int, int, char[], int), has been added to java.lang.CharSequence and java.nio.CharBuffer to bulk-read characters from a region of a CharSequence into a region of a char[]. String, StringBuilder, and CharBuffer implement CharSequence. Code that operates on a CharSequence should no longer need to special-case and cast to String when needing to bulk-read from a sequence. The new method may be more efficient than a loop over characters of the sequence.
- core-libs/java.lang Add Standard System Property stdin.encoding (JDK-8350703):
- A new system property, stdin.encoding, has been added. This property contains the name of the recommended Charset for reading character data from System.in, for example, when using InputStreamReader or Scanner. By default, the property is set in a system-specific fashion based on querying the OS and user environment. Note that its value may differ from the value of the file.encoding property, the default Charset, and the value of the native.encoding property. The value of stdin.encoding may be overridden to be UTF-8 by providing the argument -Dstdin.encoding=UTF-8 on the command line.
- See Default Charsets for Standard Output, Standard Input, and Standard Error Streams for more information.
- core-libs/java.net New Methods on BodyHandlers and BodySubscribers to Limit the Number of Response Body Bytes Accepted by the HttpClient (JDK-8328919):
- Two new methods, java.net.http.HttpResponse.BodyHandlers.limiting(BodyHandler downstreamHandler, long capacity) and java.net.http.HttpResponse.BodySubsribers.limiting(BodySubscriber downstreamSubscriber, long capacity), are added to the HttpClient API. These methods extend an existing BodyHandler or BodySubscriber with the ability to limit the number of response body bytes that the application is willing to accept in response to an HTTP request. Upon reaching the limit when reading the response body, an IOException will be raised and reported to the downstream subscriber. The subscription will be cancelled. Any further response body bytes will be discarded. This makes it possible for the application to control the maximum amount of bytes that it wants to accept from the server.
- core-libs/java.net New connectionLabel Method in java.net.http.HttpResponse to Identify Connections (JDK-8350279):
- A new connectionLabel method has been added to java.net.http.HttpResponse. This new method returns an opaque connection label that callers can leverage to associate a response with the connection it is carried on. This is useful to determine whether two requests were carried on the same connection or on different connections.
- core-libs/java.nio New Property to Construct ZIP FileSystem as Read-only (JDK-8350880):
- The ZIP file system provider is updated to allow a ZIP file system be created as a read-only or read-write file system. When creating a ZIP file system, the property name "accessMode" can be used with a value of "readOnly" or " readWrite" to specify the desired mode. If the property is not provided then the file system is created as a read-write file system if possible.
- The following example creates a read-only file system:
- FileSystem zipfs = FileSystems.newFileSystem(pathToZipFile, Map.of("accessMode","readOnly"));
- See the jdk.zipfs module description for more information on this and other properties supported by the ZIP file system provider.
- core-libs/java.util.concurrent Updates to ForkJoinPool and CompletableFuture (JDK-8319447):
- java.util.concurrent.ForkJoinPool is updated in this release to implement ScheduledExecutorService. This API update can help the performance of delayed task handling in network and other applications where delayed tasks are used for timeout handling, and where most timeouts are cancelled.
- In addition to the schedule methods defined by ScheduledExecutorService, ForkJoinPool now defines a new method submitWithTimeout to submit a task that is cancelled (or some other action executed) if the timeout expires before the task completes.
- As part of the update, CompletableFuture and SubmissionPublisher are changed so that all async methods without an explicit Executor are performed using the ForkJoinPool common pool. This differs to previous releases where a new thread was created for each async task when the ForkJoinPool common pool was configured with parallelism less than 2.
- core-libs/java.util.jar java.util.zip.Inflater and java.util.zip.Deflater Enhanced To Implement AutoCloseable (JDK-8225763):
- java.util.zip.Inflater and java.util.zip.Deflater now implement AutoCloseable and can be used with the try-with-resources statement. Applications could previously invoke the end() method to release the resources held by the Inflater/Deflater instance. Now, either the end() or the close() method can be invoked to do the same.
- core-svc Thread Dumps Generated by HotSpotDiagnosticMXBean.dumpThreads and jcmd Thread.dump_to_file Updated to Include Lock Information (JDK-8356870):
- The thread dump generated by the com.sun.management.HotSpotDiagnosticMXBean.dumpThreads API, and the diagnostic command jcmd <pid> Thread.dump_to_file, now includes lock information.
- The HotSpotDiagnosticMXBean.dumpThreads API is also updated to link to a JSON schema that describes the JSON format thread dump. The JSON format thread dump is intended to be read and processed by diagnostic tools.
- Unlike the traditional thread dump generated by jstack and jcmd <pid> Thread.print, the thread dump generated by the HotSpotDiagnosticMXBean.dumpThreads and jcmd <pid> Thread.dump_to_file does not print information about deadlocks in this release.
- hotspot/gc
- G1 Reduces Remembered Set Overhead by Grouping Regions into Shared Card Sets (JDK-8343782)
- The G1 garbage collector further reduces remembered set memory overhead and pause-time by allowing multiple regions to share a single internal structure (G1CardSet) when they are likely to be collected together during a Mixed GC.
- Previously, each region maintained its own G1CardSet, resulting in high memory overhead and redundant tracking of references between regions that would eventually be collected as a group. In the new design, regions expected to be evacuated together are grouped after the Remark phase and assigned a shared G1CardSet, eliminating the need to track references between them individually.
- This improves memory efficiency and reduces merge time during collection pauses.
- hotspot/jfr New JFR Annotation for Contextual Information (JDK-8356698):
- A new annotation, jdk.jfr.Contextual, has been introduced to mark fields in custom JFR events that contain contextual information relevant to other events occurring in the same thread. For example, fields in a user-defined HTTP request event can be annotated with @Contextual to associate its URL and trace ID with events that occur during its execution, such as a jdk.JavaMonitorEnter event due to a contended logger.
- Tools can now pair higher-level information, such as span and trace IDs, with lower-level events. The print command of the jfr tool, included in the JDK, displays this contextual information alongside JVM and JDK events, for example, in events for lock contention, I/O, or exceptions that occur during a trace span or an HTTP request event.
- hotspot/runtime UseCompactObjectHeaders Is a Product Option (JDK-8350457):
- To support use of compact object headers, two additional CDS archives for the JDK image called classes_coh.jsa and classes_nocoops_coh.jsa are provided to allow equivalent startup performance when UseCompactObjectHeaders is turned on.

security-libs/java.security Turn on Timestamp and Thread Details by Default for java.security.debug (JDK-8350689):
- The debug output from the java.security.debug system property now includes thread id, caller information, and timestamp information.

Each debug output statement generated with the java.security.debug option is now formatted as:
- componentValue[threadId|threadName|sourceCodeLocation|timestamp]: <debug statement>

where:
- componentValue is the security component value being logged.
- threadId is the hexadecimal value of the thread ID.
- threadName is the name of the thread executing the log statement.
- sourceCodeLocation is the source file and line number making this log call, in the format "filename:lineNumber".
- timestamp is the date and time in the format "yyyy-MM-dd kk:mm:ss.SSS".
- <debug statement> corresponds to the debug output from the security component.
- The +thread and +timestamp options introduced in JDK 23 will no longer have an impact and are ignored.
- More information on those legacy options is available in the JDK 23 release notes. Additional information can be found in Debug Statement Output Format.
- security-libs/java.security
- SHAKE128-256 and SHAKE256-512 as MessageDigest Algorithms (JDK-8354305)
- Two new MessageDigest algorithms, SHAKE128-256 and SHAKE256-512, have been added to the SUN provider. These are fixed-length versions of the SHAKE128 and SHAKE256 Extendable-Output Functions (XOFs) defined in NIST FIPS 202.
- For more information, see The SUN Provider.
- security-libs/javax.crypto:pkcs11
- Support for HKDF in SunPKCS11 (JDK-8328119)
- The SunPKCS11 security provider now supports the following algorithms for the new Key Derivation Function API: HKDF-SHA256, HKDF-SHA384 and HKDF-SHA512. Please refer to JDK-8344464 for further details.

security-libs/javax.net.ssl Mechanism to Disable Signature Schemes Based on Their TLS Scope (JDK-8349583):
TLS protocol specific usage constraints are now supported by the jdk.tls.disabledAlgorithms property in the java.security configuration file, as follows:

UsageConstraint:
- usage UsageType { UsageType }

UsageType:
- HandshakeSignature | CertificateSignature
- HandshakeSignature restricts the use of the algorithm in TLS handshake signatures. CertificateSignature restricts the use of the algorithm in certificate signatures. An algorithm with this constraint cannot include other usage types defined in the jdk.certpath.disabledAlgorithms property. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter.
- security-libs/javax.net.ssl
- Add Support for TLS Keying Material Exporters to JSSE and SunJSSE Provider (JDK-8341346)
- This enhancement adds support for TLS (Transport Layer Security) Keying Material Exporters, which allow applications to generate additional application-level keying material from a connection's negotiated TLS keys.
- This change enables support for several additional protocols, including those labels registered in the IANA TLS Parameters-Exporter Label document.
- This functionality is described in RFC 5705 for TLSv1-TLSv1.2, and RFC 8446 for TLSv1.3. The feature can be accessed via two new APIs in the javax.net.ssl.ExtendedSSLSession class:
- public SecretKey exportKeyingMaterialKey(String keyAlg,
- String label, byte[] context, int length) throws SSLKeyException
- public byte[] exportKeyingMaterialData(
- String label, byte[] context, int length) throws SSLKeyException
- security-libs/javax.xml.crypto
- Update XML Security for Java to 3.0.5 (JDK-8344137)
- The XML Signature implementation has been updated to Santuario 3.0.5. Support for four new SHA-3 based ECDSA SignatureMethod algorithms have been added: SignatureMethod.ECDSA_SHA3_224, SignatureMethod.ECDSA_SHA3_256, SignatureMethod.ECDSA_SHA3_384, and SignatureMethod.ECDSA_SHA3_512.
- tools/jar

Enhanced jar File Validation (JDK-8345431):
- The jar --validate command has been enhanced to identify and generate a warning message for:
- Duplicate entry names

Entry names which:
- contain a drive or device letter,
- contain a leading slash
- contains backward slashes ''
- the entry name or any path element is "." or ".."
- Inconsistencies in the ordering of entries between the LOC and CEN headers

Removed Features and Options:
- This section describes the APIs, features, and options that were removed in Java SE 25 and JDK 25. The APIs described here are those that are provided with the Oracle JDK. It includes a complete implementation of the Java SE 25 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 25 and JDK 25 is the Java SE 25 ( JSR 400) Platform Specification, which documents changes to the specification made between Java SE 24 and Java SE 25. 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 25. See CSRs Approved for JDK 25 for the list of CSRs closed in JDK 25.

core-libs/java.net java.net.Socket Constructors Can No Longer Be Used to Create a Datagram Socket (JDK-8356154):
- The two deprecated java.net.Socket constructors that accept the stream parameter have been updated to throw an IllegalArgumentException if stream is false. These constructors can no longer be used to create datagram sockets. Instead use java.net.DatagramSocket for datagram sockets. These two constructors will be removed in a future release.
- core-svc/javax.management Removal of Old JMX System Properties (JDK-8344966, JDK-8344969, JDK-8344976, JDK-8345045, JDK-8345048, JDK-8345049):
- Some very old JMX System Properties have been removed. These were compatibility aids that were intended as transitional, for later removal. New behavior will be the same as current behavior with the property unset. The removals are:
- jmx.extend.open.types which was provided to aid compatibility, since overriding javax.management.openmbean.OpenType.getClassName() was made illegal in JDK 6.
- jmx.invoke.getters was introduced in JDK 6 for compatibility with code which depended on previous, incorrect behavior, calling invoke on getters and setters.
- jdk.jmx.mbeans.allowNonPublic was introduced in JDK 8 for compatibility with previous, incorrect behavior where it was not enforced that MBean and MXBean interfaces must be public.
- jmx.mxbean.multiname was introduced in JDK 7 for compatibility with code which may have depended on previous, incorrect behavior relating to multiple registrations of an MXBean object.
- jmx.tabular.data.hash.map, which was for compatibility with JDK 1.3 clients due to use of LinkedHashMap.
- jmx.remote.x.buffer.size was a System Property and a JMX environment property. The correct name was always jmx.remote.x.notification.buffer.size and was correct from JDK 6, but the alternate name was recognized to aid compatibility.
- hotspot/runtime Removal of PerfData Sampling (JDK-8241678):
- The periodic sampling functionality in PerfData has been removed, including the StatSampler and its controlling flag -XX:PerfDataSamplingInterval.
- PerfData sampling was a rarely used mechanism that periodically updated a small set of counters in the PerfData file. For most garbage collectors, like in the G1 and ZGC collectors, it only recorded a timestamp.

With this change:
- Heap usage counters in PerfData for the Serial and Parallel garbage collectors are now only updated after each garbage collection cycle. As a result, the Eden space usage counter (sun.gc.generation.0.space.0.used) will always show zero, since the space is empty after collection. Accurate values are still available through tools such as the Java Flight Recorder (JFR) and Java Management Extensions (JMX)
- The sun.os.hrt.ticks counter tracking time since JVM startup has been removed. This can instead be derived from sun.rt.createVmBeginTime.
- The -XX:PerfDataSamplingInterval flag has been made obsolete, and will be removed in a future release.
- This change only affects tools that read data directly from the PerfData file. Other monitoring programs and tools remain unaffected.
- hotspot/runtime Removal of sun.rt._sync* Performance Counters (JDK-8348829):
- This release removes old object monitor performance counters, exposed in the sun.rt._sync* namespace. These counters were seldom used, and they contributed to performance problems in related VM code. Users who want to track monitor performance are advised to use related JFR events instead.

The suggested replacements are:
- _sync_ContendedLockAttempts: JavaMonitorEnter JFR event
- _sync_FutileWakeups: no replacement
- _sync_Parks: JavaMonitorWait JFR event
- _sync_Notifications: JavaMonitorNotify JFR event
- _sync_Inflations: JavaMonitorInflate JFR event
- _sync_Deflations: JavaMonitorDeflate JFR event
- _sync_MonExtant: JavaMonitorStatistics JFR event

security-libs/java.security Removed Baltimore CyberTrust Root Certificate After Expiry Date (JDK-8303770):
- The following expired root certificate has been removed from the cacerts keystore:
- + alias name "baltimorecybertrustca [jdk]"
- Distinguished Name: CN=Baltimore CyberTrust Root, OU=CyberTrust, O=Baltimore, C=IE
- security-libs/java.security
- Removed Two Camerfirma Root Certificates (JDK-8350498)
- The following root certificates, which are terminated and no longer in use, have been removed from the cacerts keystore:
- + alias name "camerfirmachamberscommerceca [jdk]"
- Distinguished Name: CN=Chambers of Commerce Root, OU=http://www.chambersign.org, O=AC Camerfirma SA CIF A82743287, C=EU
- + alias name "camerfirmachambersignca [jdk]"
- Distinguished Name: CN=Global Chambersign Root - 2008, O=AC Camerfirma S.A., SERIALNUMBER=A82743287, L=Madrid (see current address at www.camerfirma.com/address), C=EU
- security-libs/javax.crypto:pkcs11
- Removal of SunPKCS11 Provider's PBE-related SecretKeyFactory Implementations (JDK-8348732)
- Starting with JDK 21, the SunPKCS11 provider added several password-based SecretKeyFactory implementations, such as:
- SecretKeyFactory.PBEWithHmac[MD]AndAES_128
- SecretKeyFactory.PBEWithHmac[MD]AndAES_256
- SecretKeyFactory.HmacPBE[MD]
- where [MD] is one of the SHA1, SHA224, SHA256, SHA384, and SHA512 algorithms.
- However, the key objects produced by these implementations use the PBKDF2-derived values as key encodings. This is different than the SunJCE counterparts which use the password bytes as key encodings. These differences can be very confusing and may cause interoperability issues since both keys have the same algorithm and format, but different encodings. Thus, for consistency sake, these SunPKCS11 password-based SecretKeyFactory implementations have been removed.

Deprecated Features and Options:
- Additional sources of information about the APIs, features, and options deprecated in Java SE 25 and JDK 25 include:
- The Deprecated API page identifies all deprecated APIs including those deprecated in Java SE 25.
- The Java SE 25 ( JSR 400) specification documents changes to the specification made between Java SE 24 and Java SE 25 that include the identification of deprecated APIs and features not described here.
- 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 25. See CSRs Approved for JDK 25 for the list of CSRs closed in JDK 25.
- core-libs/java.lang Deprecate VFORK Launch Mechanism from Process Implementation (linux) (JDK-8357179):
- On Linux, the -Djdk.lang.Process.launchMechanism=VFORK option has been deprecated due to being inherently dangerous. It will be removed in a future release.
- Customers are advised to avoid using this property. If possible, they should remove it and use the default launch mechanism based on posix_spawn. In case that is not possible, they should use -Djdk.lang.Process.launchMechanism=FORK instead.

core-libs/java.util:i18n Deprecate the Use of java.locale.useOldISOCodes System Property (JDK-8353118):
- The java.locale.useOldISOCodes system property has been deprecated. Introduced in JDK 17, it allowed users to revert to the legacy ISO 639 language codes for Hebrew, Indonesian, and Yiddish. Since its purpose was to facilitate a transition to the updated codes, we believe it is now time to retire it. In JDK 25, setting this property to true has no effect, and a warning about its future removal is displayed at runtime.
- core-svc/javax.management Deprecate XML Interchange in JMX DescriptorSupport for Removal (JDK-8347433):
- The JMX class javax.management.modelmbean.DescriptorSupport represents MBean metadata. It has a constructor and a method providing creation from, and export to, XML. These are unused in the JDK and have no commonly known wider usage, and are deprecated for removal. The class javax.management.modelmbean.XMLParseException, which is only thrown by DescriptorSupport, is also deprecated for removal. This will have no impact on JMX features in general.
- hotspot/runtime The UseCompressedClassPointers Option is Deprecated (JDK-8350753):
- The option UseCompressedClassPointers is deprecated in Java SE 25 and will be removed in a future Java version.
- This option was used to switch between two modes:
- The compressed class pointer mode (-XX:+UseCompressedClassPointers, default if the switch is not specified)
- The uncompressed class pointer mode (-XX:-UseCompressedClassPointers)
- The uncompressed class pointer mode will be removed in a future version of Java. Since that only leaves the default compressed class pointer mode, the switch will also be removed.
- The uncompressed class pointer mode causes the JVM to use more memory. It serves very little purpose today.
- The default compressed class pointer mode causes the JVM to place classes into the class space. The class space is limited by default to 1GB and can hold up to about 1.5 million classes. In the rare case that an application must load more than that, the class space can be extended up to 4 GB with -XX:CompressedClassSpaceSize . That increases the number of classes the class space can hold to approximately 6 million classes.
- Note that these numbers are extremely high. It is rare even for a huge Java application to even load more than 100,000 classes. If your application loads significantly more classes than that, it is very likely a pathological situation, such as a class loader leak.
- The class space is reserved up front when the JVM starts. However, that memory is virtual; no actual memory is used until classes are loaded, and then, only as many pages are allocated as are needed to hold the class data.
- If your application specifies -XX:+UseCompressedClassPointers, remove that option. It is superfluous since enabling compressed class pointers is the default.
- If your application specifies -XX:-UseCompressedClassPointers, remove that option. In all likelihood, the application will just continue to work. Should the application exhaust the class space, you may want to examine whether that situation is pathological. If it is not pathological, increase the class space to 4GB using -XX:CompressedClassSpaceSize=4g.
- security-libs/java.security
- Various Permission Classes Deprecated for Removal (JDK-8348967, JDK-8347985, JDK-8351224, JDK-8351310, JDK-8353641, JDK-8353642, JDK-8353856)

The following permission classes have been deprecated for removal:
- java.security.UnresolvedPermission
- javax.net.ssl.SSLPermission
- javax.security.auth.AuthPermission
- javax.security.auth.PrivateCredentialPermission
- javax.security.auth.kerberos.DelegationPermission
- javax.security.auth.kerberos.ServicePermission
- com.sun.security.jgss.InquireSecContextPermission
- java.lang.RuntimePermission
- java.lang.reflect.ReflectPermission
- java.io.FilePermission
- java.io.SerializablePermission
- java.nio.file.LinkPermission
- java.util.logging.LoggingPermission
- java.util.PropertyPermission
- jdk.jfr.FlightRecorderPermission
- java.net.NetPermission
- java.net.URLPermission
- jdk.net.NetworkPermission
- com.sun.tools.attach.AttachPermission
- com.sun.jdi.JDIPermission
- java.lang.management.ManagementPermission
- javax.management.MBeanPermission
- javax.management.MBeanTrustPermission
- javax.management.MBeanServerPermission
- javax.management.remote.SubjectDelegationPermission
- In addition, the getPermission method defined in java.net.URLConnection and its subclass java.net.HttpURLConnection has been deprecated for removal.
- These permission classes and associated methods were only useful in conjunction with the Security Manager, which is no longer supported.
- Notable Issues Resolved:
- The following notes describe previous known issues or limitations that have been corrected in this release.

core-libs/java.lang.classfile CodeModel Now Delivers Custom and Unknown Attributes (JDK-8347472):
- In the previous release, when a java.lang.classfile.CodeModel is traversed by a forEach, CustomAttribute and UnknownAttribute were not delivered. Now, they are delivered, bringing their delivery behavior in parity with ClassModel, FieldModel, and MethodModel.
- Users who traverse a CodeModel should review their handling of these two attributes when they are delivered as CodeElement. In particular, users using exhaustive pattern matching switches to handle CodeElement will encounter a compile error and must update their code.

core-libs/java.util:i18n Japanese Imperial Calendar Exception Change for Era too Large (JDK-8350646):
- Calling Calendar.computeTime() with a Japanese Imperial Calendar for a Calendar.ERA field value that is too large now throws IllegalArgumentException instead of ArrayIndexOutOfBoundsException. Thus, any operations requiring time recomputation for a Japanese Imperial Calendar are now affected. For example, at the time of this release note, new Calendar.Builder().setCalendarType("japanese").set(Calendar.ERA, 6).build() now throws IllegalArgumentException.
- hotspot/gc No More OutOfMemoryErrors Due to JNI in Serial/Parallel GC (JDK-8192647):
- Serial and Parallel garbage collectors now ensure that no Java threads are in a JNI critical region before initiating a garbage collection eliminating unnecessary OutOfMemoryErrors.
- Previously, garbage collection could early-return without reclaiming any memory if any thread remained in such a region. This could lead to unexpected OutOfMemoryErrors (OOMEs), as garbage collection might not have had a chance to reclaim memory even after a few retries. Increasing GCLockerRetryAllocationCount has often been suggested as a workaround for avoiding this kind of premature OOME.
- With this change, a pending garbage collection request will wait for all Java threads to exit JNI critical regions and block new entries. This guarantees that once inside the safepoint, no threads remain in critical regions and garbage collection can always proceed to completion. As a result, the diagnostic flag GCLockerRetryAllocationCount has been removed, as it is no longer necessary.
- hotspot/gc G1 Reduces Pause Time Spikes by Improving Region Selection (JDK-8351405):
- The G1 garbage collector now addresses pause time spikes during Mixed GCs by improving the selection of memory regions to reclaim during those. Regions that are expected to be costly to collect due to high inter-region references may be excluded during this region selection.
- Using additional information gathered during the marking phase, G1 can better estimate the cost of collecting each region and skip those that would significantly impact pause times. The result is reduced pause time spikes, particularly toward the end of a Mixed GC cycle, improving overall application performance.
- hotspot/gc ZGC Now Avoids String Deduplication for Short-Lived Strings (JDK-8347337):
- ZGC's String Deduplication feature has been updated to skip deduplication for young, short-lived strings. This change reduces unnecessary processing and can improve performance in applications that frequently allocate temporary strings.

hotspot/runtime Class Files Provided With The JVMTI ClassFileLoadHook Event Are Verified (JDK-8351654):
- When providing a class with JVMTI ClassFileLoadHook, the new bytecodes are verified with the Class File Verifier even if they are provided on the bootclass path, and regardless of the setting of the deprecated -Xverify option.

Other Notes:
- The following notes describe additional changes and information about this release. In some cases, the following descriptions provide links to additional detailed information about an issue or a change.

client-libs/2d JDK Provided Instances of ICC_Profile Cannot Be Modified (JDK-8346465):
- The desktop module provides the ICC_Profile class used in Color Management for image processing applications. Previously, an ICC_Profile instance would always allow an application to modify the raw color profile data which the ICC_Profile encapsulates. However, instances of this class provided by the desktop module itself are shared and should never be modified. JDK now enforces this restriction on these shared instances. As a result, application code which modifies a shared instance of ICC_Profile will cause an exception to be thrown.
- client-libs/javax.swing Removal of No-Argument Constructor for BasicSliderUI() (JDK-8334581):
- Several hundred classes in the java.desktop module used to rely on default constructors as part of their public API. Explicit constructors were added to these classes in JDK-8250852.
- As a result, a no-argument constructor, BasicSliderUI(), for the BasicSliderUI class was added in JDK 16. This missed that there already was a constructor BasicSliderUI(JSlider b). Thus, there was no need for another constructor.
- The BasicSliderUI() constructor was deprecated in JDK 23 and is removed in JDK 25.
- core-libs/java.io Default Console Implementation No Longer Based On JLine (JDK-8351435):
- The default Console obtained via System.console() is no longer based on JLine. Since JDK 20, the JDK has included a JLine-based Console implementation, offering a richer user experience and better support for virtual terminal environments, such as IDEs. This implementation was initially opt-in via a system property in JDK 20 and JDK 21 and became the default in JDK 22. However, maintaining the JLine-based Console proved challenging. As a result, in JDK 25, it has reverted to being opt-in, as it was in JDK 20 and JDK 21.

core-libs/java.io java.io.File.delete No Longer Deletes Read-only Files on Windows (JDK-8355954):
- File.delete is changed on Windows so that it now fails and returns false for regular files when the DOS read-only attribute is set. Prior to JDK 25, File.delete deleted read-only files by removing this DOS attribute before attempting to delete. As removing the attribute and deleting the file do not comprise a single atomic operation, this could result in the file still existing but with modified attributes if the deletion were to fail. Applications that depend on long standing behavior should be changed to clear the file attributes prior to deletion.
- As part of the change, a system property has been introduced to restore long standing behavior. Running with -Djdk.io.File.allowDeleteReadOnlyFiles=true will restore old behavior so that File.delete removes the DOS read-only attribute before attempting to delete the file.
- core-libs/java.io File Operations with Directory or File Names Ending in a Space Now Consistently Fail on Windows (JDK-8354450):
- File operations on a path with a trailing space in a directory or file name, such as "C:SomeFolderSomeFile ", now fail consistently on Windows. For example, File::mkdir will return false, or File::createNewFile will throw IOException if an element in the path has a trailing space. Such pathnames are not legal on Windows. Prior to JDK 25, operations on a File created from such an illegal abstract pathname could appear to succeed when in fact they did not.

core-libs/java.io java.io.File Treats the Empty Pathname As the Current User Directory (JDK-8024695):
- The java.io.File class is changed so that an instance of File created from the empty abstract pathname ("") now behaves consistently like a File created from the current user directory. Long standing behavior was for some methods to fail for the empty pathname. The change means that the canRead, exists, and isDirectory methods return true instead of failing with false, and the getFreeSpace, lastModified, and length methods return the expected values instead of zero. Methods such as setReadable and setLastModified will attempt to change the file's attributes instead of failing. WIth this change, java.io.File now matches the behavior of the java.nio.file API.
- core-libs/java.lang Relax String Creation Requirements in StringBuilder and StringBuffer (JDK-8138614):
- The specifications of the substring, subSequence, and toString methods of the StringBuilder and StringBuffer classes have changed not to require a new String instance to be returned every time. This allows implementations to improve performance by returning an already-existing string, such as the empty string, when that is appropriate. In all cases, a String containing the expected value will be returned. However, applications should not depend on these methods to return a new String instance every time.

core-libs/java.math Method BigDecimal.sqrt() Might Now Throw on Powers of 100 and Huge Precisions (JDK-8341402):
- The method BigDecimal.sqrt() has been reimplemented to perform much better.
- However, in some very rare and quite artificial cases involving powers of 100 and huge precisions, the new implementation throws whereas the old one returns a result.
- For example:
- BigDecimal.valueOf(100).sqrt(new MathContext(1_000_000_000, RoundingMode.UP))
- returns 10 in the old implementation. Note, however, that rather than returning 11, it throws when evaluating
- BigDecimal.valueOf(121).sqrt(new MathContext(1_000_000_000, RoundingMode.UP))
- Indeed, the old implementation treats powers of 100 as special cases (see 1st example). Other exact squares are treated normally, so throw when the requested precision is too high (see 2nd example). This special behavior for powers of 100 is not recommended, as it is more confusing than helpful when compared to other exact squares.
- The new implementation is agnostic about powers of 100, and throws whenever internal intermediate results would exceed supported ranges. In particular, it uniformly throws on both the examples above.
- core-libs/java.net FTP Fallback for Non-Local File URLs Is Disabled by Default (JDK-8353440):
- The unspecified, but long-standing, fallback to FTP connections for non-local file URLs is disabled by default.
- The method URL::openConnection called for non-local file URLs of the form "file://server[/path]", where server is anything but "localhost", no longer falls back to FTP and no longer returns an FTP URL Connection. A MalformedURLException is now thrown by the URL::openConnection method instead in such cases.
- Code expecting the URL::openConnection to succeed, but expecting a delayed exception to be raised when actually using the connection, such as catching an UnknownHostException while reading streams, may need to be updated to handle the immediate rejection via MalformedURLException instead.
- The legacy FTP fallback behavior can be reenabled by setting the system property -Djdk.net.file.ftpfallback=true on the java command line. Support for resolving non-local, existing UNC paths on Windows is not affected by this change.

core-libs/java.net The jwebserver Tool -d Command Line Option Now Accepts Directories Specified With a Relative Path (JDK-8355360):
The jwebserver tool is updated to allow the -d and --directory command line options, configuring the directory to serve, to accept a directory specified with a relative path. This is made available both when jwebserver is invoked as an executable:
- jwebserver --directory some/relative/path
- and as a module:
- java --module jdk.httpserver --directory some/relative/path
- As earlier, -d and --directory command line options also still support absolute paths

core-libs/java.net Networking Exception Messages can be Filtered to Remove Sensitive Information (JDK-8348986):
- Usage of the jdk.includeInExceptions security and system property has been expanded to include more networking exception messages and more categories that can be configured as enabled or disabled. Please refer to the Enhanced exception message information section of the conf/security/java.security configuration file for more information.

core-libs/java.net java.net.http.HttpClient is Enhanced to Reject Responses with Prohibited Headers (JDK-8354276):
- The java.net.http.HttpClient will now reject HTTP/2 responses that contain header fields prohibited by the HTTP/2 specification (RFC 9113). This is an implementation detail that should be transparent to the users of the HttpClient API, but could result in failed requests if connecting to a non-conformant HTTP/2 server.
- The headers that are now rejected in HTTP/2 responses include:
- connection-specific header fields (Connection, Proxy-Connection, Keep-Alive, Transfer-Encoding, and Upgrade)
- request pseudo-header fields (:method, :authority, :path, and :scheme)

core-libs/java.nio The Default Thread Pool Used for Asynchronous Channel Operations Now Uses Innocuous Threads (JDK-8345432):
- The default thread pool for the system-wide default AsynchronousChannelGroup is changed to create threads that do not inherit anything from threads that initiate asynchronous I/O operations. Historically, threads in the default thread pool inherited the Thread Context ClassLoader (TCCL) and inheritable-ThreadLocals from the first thread to initiate an asynchronous I/O operation. The change in this release avoids potential memory leak and retention issues that arose when a TCCL or a thread local kept a large graph of objects reachable.

core-libs/java.util.jar:
- Added API Note on Validating Signers to the getCertificates and getCodeSigners Methods of JarEntry and JarURLConnection (JDK-8347946)
- An API note has been added to the getCertificates() method of the java.util.jar.JarEntry and java.net.JarURLConnection classes and the getCodeSigners() method of the JarEntry class recommending that the caller should perform further validation steps on the code signers that signed the JAR file, such as validating the code signer's certificate chain, and determining if the signer should be trusted.
- In addition, the JarURLConnection.getCertificates() method has been updated to specify the order of the returned array of certificates. It is the same order as specified by java.util.jar.JarEntry.getCertificates().
- core-libs/java.util:i18n Changes to the Default Time Zone Detection on Debian-based Linux (JDK-8345213):
- On Debian-based Linux distributions such as Ubuntu, the /etc/timezone file was previously used to determine the JDK's default time zone (TimeZone.getDefault()). According to Debian's Wiki, /etc/localtime is now the primary source for the system's default time zone, making /etc/timezone redundant. As a result, the JDK's default time zone detection logic has been updated to use /etc/localtime instead of /etc/timezone. If /etc/localtime and /etc/timezone are inconsistent for any reason, the JDK's default time zone is now determined solely based on /etc/localtime file.

core-libs/java.util:i18n Support for CLDR Version 47 (JDK-8346948):
- The locale data based on the Unicode Consortium's CLDR has been upgraded to version 47. Besides the usual addition of new locale data and translation changes, there are notable changes from the upstream CLDR, affecting Date/Time/Number formattings:
- CLDR-9791: Add language for South Georgia and Bouvet Islands (#4166)
- CLDR-16821: Fix Australian time zone names (#4301)
- CLDR-17484: English day periods are wrong (#4375)
- CLDR-18099: Add European English locales with data (#4276, (#4302)
- CLDR-18268: Add timeData for GS (#4319)
- Note that locale data is subject to change in a future release of the CLDR. Although not all locale data changes affect the JDK, users should not assume stability across releases. For more details, please refer to the Unicode Consortium's CLDR release notes and their locale data deltas.

core-svc/tools JarInputStream Treats Signed JARs with Multiple Manifests As Unsigned (JDK-8337494 (not public)):
- The JarInputStream class now treats a signed JAR as unsigned if it detects a second manifest within the first two entries in the JAR file. A warning message "WARNING: Multiple MANIFEST.MF found. Treat JAR file as unsigned." is logged if the system property, -Djava.security.debug=jar, is set.
- core-svc/tools JAR Files on Classpath Are Never Modified by javac (JDK-8338675):
- Under some conditions, javac could have modified jar or zip files places on the classpath, by writing classfile(s) to them.
- The specific conditions are:
- no output directory specified (that is, no -d option)
- no -sourcepath specified
- the jar or zip file on the classpath contains source file(s), which are compiled implicitly
- This is no longer the case. Classfiles will never be written to jar or zip files. Those that would be written into the jar or zip file will be placed to the current working directory. This mimics the JDK 8 behavior.

hotspot/compiler MontgomeryIntegerPolynomialP256 Multiply Intrinsic with AVX2 on x86_64 (JDK-8350459):
- This feature delivers optimized intrinsics using AVX2 instructions on x86_64 platforms for the P256 Elliptic Curve field operations in the SunEC provider. This optimization is enabled by default on supporting x86_64 platforms and when the AVX512 intrinsic cannot be used. It may be disabled by providing the -XX:+UnlockDiagnosticVMOptions -XX:-UseIntPolyIntrinsics command-line options.
- hotspot/gc ZGC: Enhanced Methods for Dealing With Fragmentation (JDK-8350441):
- ZGC has been improved to better deal with virtual address space fragmentation. This is especially impactful for programs with a large heap, where virtual address space fragmentation could be a noticeable issue.
- ZGC no longer reports inflated RSS-usage of the Java heap. This comes as a consequence of removing asynchronous unmapping, which was the last usage of multi-mapped memory.
- hotspot/gc Information About Metaspace Has Been Moved Away from Heap Logging (JDK-8356848):
- Most information about Metaspace that was previously printed by the Garbage Collector (GC) is now available in Metaspace-specific logging.
- To get information about Metaspace that was formerly part of the GC.heap_info jcmd, use the existing VM.metaspace jcmd instead.

hotspot/jfr Socket, File, and Exception Events for JFR Are Throttled by Default (JDK-8351594):
- Previously, the events jdk.SocketRead, jdk.SocketWrite, jdk.FileRead, and jdk.FileWrite were recorded if the duration exceeded 20 ms in the default configuration (default.jfc). The threshold has been lowered to 1 ms. To prevent a high volume of events, a rate limit of 100 events per second is imposed on these events. To restore the previous behavior, you can set the throttle setting to "off" and the threshold to "20 ms". For example:
- -XX:StartFlightRecording:jdk.SocketRead#threshold=20ms,jdk.SocketRead#throttle=off
- The jdk.JavaExceptionThrow event was previously disabled by default, but is now enabled by default with a rate limit of 100 events per second. To disable this event, use:
- -XX:StartFlightRecording:jdk.JavaExceptionThrow#enabled=false
- hotspot/jvmti NotifyFramePop Should Return JVMTI_ERROR_DUPLICATE (JDK-8346460):
- The JVMTI function NotifyFramePop returns JVMTI_ERROR_DUPLICATE in the case a FramePop event was already requested at the specified depth.
- hotspot/runtime Compact Object Headers CDS Archive Generation and jlink Instruction (JDK-8350457):
- If using -XX:+UseCompactObjectHeaders with a custom image created with jlink, an additional step is needed to create the CDS archives for this configuration. After creating the image, do:
- <image>/bin/java -XX:+UseCompactObjectHeaders -Xshare:dump
- to create the classes_coh.jsa file. In the unlikely case that you wish to use UseCompactObjectHeaders without UseCompressedOops, also create a CDS archive image by:
- <image>/bin/java -XX:+UseCompactObjectHeaders -XX:-UseCompressedOops -Xshare:dump
- install/install
- Use systemd Instead of init for jexec (JDK-8355072 (not public))
- Linux RPM JDK installers now use systemd instead of init to manage the automatic jar file execution (jexec) service.
- security-libs/java.security Added 4 New Root Certificates from Sectigo Limited (JDK-8359170):
- The following root certificates have been added to the cacerts truststore:
- + Sectigo Limited
- + sectigocodesignroote46
- DN: CN=Sectigo Public Code Signing Root E46, O=Sectigo Limited, C=GB
- + Sectigo Limited
- + sectigocodesignrootr46
- DN: CN=Sectigo Public Code Signing Root R46, O=Sectigo Limited, C=GB
- + Sectigo Limited
- + sectigotlsroote46
- DN: CN=Sectigo Public Server Authentication Root E46, O=Sectigo Limited, C=GB
- + Sectigo Limited
- + sectigotlsrootr46
- DN: CN=Sectigo Public Server Authentication Root R46, O=Sectigo Limited, C=GB
- security-libs/java.security
- Added TLSv1.3 and CNSA 1.0 Algorithms to Implementation Requirements (JDK-8283795)
- TLSv1.3 and CNSA 1.0 algorithms have been added to the list of cryptographic requirements all Java SE implementations must support. All cryptographic algorithms that are needed to implement the TLSv1.3 cipher suites and signature mechanisms and that are defined by RFC 8446 as MUST or SHOULD requirements have been added. All algorithms that are required by CNSA 1.0 have also been added. No required algorithms or protocols are being removed at this time.
- The following requirements have been added to the Security Algorithm Implementation Requirements section of the Java Security Standard Algorithm Names specification and to the class summary of each of the APIs below.
- AlgorithmParameters
- ChaCha20-Poly1305
- EC with secp256r1 or secp384r1 curves
- RSASSA-PSS with MGF1 mask generation function and SHA-256 or SHA-384 hash algorithm
- Cipher
- AES/GCM/NoPadding with 256 bit key size
- ChaCha20-Poly1305
- KeyAgreement
- ECDH with secp256r1 or secp384r1 curves
- X25519
- KeyFactory
- RSASSA-PSS
- X25519
- KeyGenerator
- AES with 256 bit key size
- ChaCha20
- KeyPairGenerator
- DH with 3072 bit key size
- EC with secp256r1 or secp384r1 curves
- RSA with 3072 bit key size
- RSASSA-PSS with 2048, 3072, 4096 bit key sizes
- X25519
- MessageDigest
- SHA-384
- Signature
- RSASSA-PSS with MGF1 mask generation function and SHA-256 or SHA-384 hash algorithm
- SHA256WithECDSA with secp256r1 curve
- SHA384WithECDSA with secp384r1 curve
- SHA384WithRSA
- SSLContext
- TLSv1.3

security-libs/java.security ML-DSA Performance Improved (JDK-8351034, JDK-8348561):
- The performance of the ML-DSA key generation, sign, and verify operations has been improved significantly, 1.5 - 2.5 times depending on operation type and input, on the aarch64 and AVX-512 platforms.
- security-libs/java.security Compatible OCSP readtimeout Property with OCSP Timeout (JDK-8347506):
- In JDK 21, an enhanced syntax for various timeout properties was released through JDK-8179502. This included a new system property, com.sun.security.ocsp.readtimeout, which allows users to control the timeout while reading OCSP responses after a successful TCP connection has been established.
- This changes the default posture of this property to be the value of the com.sun.security.ocsp.timeout system property from its original default of 15 seconds. If the com.sun.security.ocsp.timeout system property is also not set, then its default 15 second timeout is propagated to the default for com.sun.security.ocsp.readtimeout.
- For more information, see Appendix B: CertPath Implementation in SUN Provider.
- security-libs/javax.crypto SunJCE Provider's PBE-related SecretKeyFactory Implementations Enhanced with Unicode Support (JDK-8348732):
- The password-based SecretKeyFactory implementations from the SunJCE provider used to reject non-ASCII passwords. They have been enhanced to use UTF-8 and thus allow Unicode characters to be used as passwords.
- security-libs/javax.crypto ML-KEM Performance Improved (JDK-8351412, JDK-8349721):
- The performance of the ML-KEM key generation, encapsulation, and decapsulation operations has been improved significantly, 1.9 - 2.7 times depending on operation type and platform, on the aarch64 and AVX-512 platforms.
- security-libs/javax.net.ssl Disabled SHA-1 in TLS/DTLS 1.2 Handshake Signatures (JDK-8340321):
- The SHA-1 algorithm has been disabled by default in TLS/DTLS 1.2 handshake signatures, by adding "rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature" to the jdk.tls.disabledAlgorithms security property in the java.security config file. RFC 9155 deprecates the use of SHA-1 in TLS & DTLS 1.2 digital signatures. Users can, at their own risk, re-enable the SHA-1 algorithm in TLS/DTLS 1.2 handshake signatures by removing "rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, dsa_sha1 usage HandshakeSignature" from the jdk.tls.disabledAlgorithms security property.

tools/javac Inner Classes Must Not Have null as their Immediately Enclosing Instance (JDK-8164714):
- In Java programs, every instance of an inner class has an immediately enclosing instance. When an inner class is instantiated with the new keyword, the immediately enclosing instance is passed to the inner class's constructor via a parameter not visible in source code. The Java Language Specification (§15.9.4) requires that the immediately enclosing instance is not null.
- Prior to JDK 25, javac inserted a null check on the immediately enclosing instance before it was passed to the inner class's constructor. No null check was performed in the body of the inner class's constructor. As a result, it was possible to use core reflection, e.g., java.lang.reflect.Constructor::newInstance, or specially crafted class files to invoke an inner class's constructor with null as the immediately enclosing instance. This could lead to unexpected program failures.
- In JDK 25, javac inserts an additional null check on the immediately enclosing instance. This check occurs in the body of the inner class's constructor. As a result, there is no way to instantiate an inner class with null as the immediately enclosing instance.
- In the extremely rare case of needing to run legacy code that passes null as the immediately enclosing instance, developers can, at their own risk, use the unsupported option -XDnullCheckOuterThis=false. This prevents javac from inserting the additional null check in inner class constructor bodies.

tools/javac javac Mishandles Supplementary Character in Character Literal (JDK-8354908):
- In the Java source code, character literals can only contain a single UTF-16 character. The javac compiler was incorrectly accepting character literals consisting of two UTF-16 surrogate characters, only using the first surrogate, and ignoring the second surrogate. This has now been corrected, and javac will produce a compile-time error when it detects a character literal which consists of two UTF-16 surrogate characters.
- tools/javac -Xprint Output Includes Type Variable Bounds and Annotated Object Supertypes (JDK-8356057):
- The output for -Xprint has been updated to include bounds for type variables and java.lang.Object as a supertype, if the supertype is annotated.

tools/javac The javac Compiler Should Not Accept a Lambda Expression Type to Be a Class (JDK-8322810):
- Prior to JDK 25, the javac compiler was allowing the type of lambda expressions to be classes in some cases.
- Starting from JDK 25 the javac compiler will reject lambda expressions which type is a class
- tools/javac The -Xlint:none Compiler Flag No Longer Implies -nowarn (JDK-8352612):
- The -Xlint command line flag for javac is used to enable or disable categories of lint warnings generated during compilation. For example, -Xlint:all,-serial enables all lint categories and then disables the serial category, while the converse -Xlint:none,serial disables all lint categories and then enables the serial category.
- For historical reasons, the appearance of -Xlint:none also had the invisible side effect of disabling _all_ non-mandatory warnings, exactly as if the flag -nowarn had also been given. As a result, the effect of a flag like -Xlint:none,serial was to simply disable all non-mandatory warnings; in particular, no warnings in the serial category would be generated.
- This invisible side-effect has been eliminated. Now -Xlint:none simply disables all lint categories, and a flag like -Xlint:none,serial will allow serial warnings to appear as expected.
- tools/javadoc(tool) Hide Superclasses from Conditionally Exported Packages (JDK-8254622):
- JavaDoc now treats classes and interfaces from packages that are not exported or exported by qualified export as hidden unless they are explicitly included in the documentation. Such classes and interfaces do not appear in the generated documentation, even if they are extended or implemented by a documented type. Other instances of hidden types are private or package-private types, or types marked with the @hidden JavaDoc tag.
- tools/javadoc(tool) Whitespace Normalization in Traditional Documentation Comments (JDK-8352249):
- JavaDoc now strips common indentation from the beginning of lines in traditional documentation comments, as it already does in Markdown documentation comments. This prevents unintentional whitespace in preformatted code samples using the HTML <pre> element while preserving the relative indentation of lines.
- tools/javadoc(tool) Syntax Highlighting for Code Fragments (JDK-8348282):
- JavaDoc provides a new --syntax-highlight option to enable syntax highlighting in {@snippet} tags and <pre><code> HTML elements. The option takes no arguments and adds the Highlight.js library to the generated documentation in a configuration that supports Java, Properties, JSON, HTML and XML code fragments.

tools/javadoc(tool) Keyboard Navigation (JDK-8350638):
- API documentation generated by javadoc no longer sets the keyboard focus to the search input field on page load. Instead, it provides keyboard shortcuts to manage keyboard focus. Press the / key to set the focus on the search input, the . key to set the focus on the filter input in the sidebar, and the Esc key to release the focus from either input field. Furthermore, content in the sidebar and search page can now be navigated using the Tab and arrow keys.
- For more information, see Keyboard Navigation in the JavaDoc API documentation.

tools/jpackage jpackage No Longer Includes Service Bindings by Default for Generated Run-Time Images (JDK-8345185):
- Starting with JDK 25, jpackage no longer includes service bindings for a run-time image that it creates. Prior to JDK 25, jpackage would include service bindings for run-time images. As a result, the generated run-time images produced by jpackage might not include the same set of modules as it did in prior versions.
- The previous behavior can be achieved by adding the --bind-services jlink option to the default jlink options jpackage uses:
- jpackage [...] --jlink-options
- "--strip-native-commands --strip-debug --no-man-pages --no-header-files --bind-services"
- For more information, see Java Runtime Requirements.
- xml/jaxp
- Streamline XPath API's Extension Function Control (JDK-8354084)
- Restrictions on extension functions has been removed in the XPath API, specifically those imposed by FEATURE_SECURE_PROCESSING (FSP) and the jdk.xml.enableExtensionFunctions property. Previously, for extension functions to work, even with a user-defined XPathFunctionResolver, FSP had to be set to false and jdk.xml.enableExtensionFunctions true. For example, an XPath created via the following factory would fail with an XPathExpressionException when encountering an Extension Function:
- XPathFactory xpf = XPathFactory.newInstance();
- xpf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
- With this change, extension functions now work solely based on the presence of a properly registered XPathFunctionResolver, making extension straightforward:
- XPathFactory xpf = XPathFactory.newInstance();
- xpf.setXPathFunctionResolver(new MyXPathFunctionResolver());
- The default value of FSP has also been changed from false to true. Since extension functions are no longer governed by this setting, and the default XPath limits already conform to the secure configurations, this update has no effect on standard XPath behavior.
- Additional information can be found in The FEATURE_SECURE_PROCESSING Security Directive and The JAXP Property for Extension Functions.
- xml/jaxp Corrected Error Handling for XMLStreamReader (JDK-8327378):
- Fixed XMLStreamReader's error handling where its next() method incorrectly threw EOFException instead of the documented XMLStreamException when encountering a premature end of file.

Differences Between Oracle JDK and OpenJDK:
- Although we have stated the goal to have Oracle JDK and OpenJDK binaries be as close to each other as possible, there remain several differences between the two options.

The current differences are:
- Oracle JDK offers "installers" (msi, rpm, deb, etc.) which not only place the JDK binaries in your system but also contain update rules and in some cases handle some common configurations like set common environmental variables (such as, JAVA_HOME in Windows) and establish file associations (such as, use java to launch .jar files). OpenJDK is offered only as compressed archive (tar.gz or .zip).
- Usage Logging is only available in Oracle JDK.
- Oracle JDK requires that third-party cryptographic providers be signed with a Java Cryptography Extension (JCE) Code Signing Certificate. OpenJDK continues allowing the use of unsigned third-party crypto providers.
- The output of java -version is different. Oracle JDK returns java and includes the Oracle-specific identifier. OpenJDK returns OpenJDK and does not include the Oracle-specific identifier.
- Oracle JDK will be released under the Oracle No-Fee Terms and Conditions License. OpenJDK is released under GPLv2wCP. License files included with each will therefore be different.
- Oracle JDK distributes FreeType under the FreeType license and OpenJDK does so under GPLv2. The contents of legaljava.desktopfreetype.md is therefore different.
- Oracle JDK has Java cup and steam icons and OpenJDK has Duke icons.
- Oracle JDK source code includes "ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms." Source code distributed with OpenJDK refers to the GPL license terms instead.