JDK 23 RDP2 | Removal of the legacy COMPAT locale provider and more heads-up!
Welcome to the OpenJDK Quality Outreach summer update. JDK 23 is now in Rampdown Phase Two [1], its overall feature has been frozen a few weeks ago. Per the JDK Release Process, we have now turned our focus to P1 and P2 bugs, which can be fixed with approval [2]. Late enhancements are still possible, with approval, but the bar is now extraordinarily high. That also means that the JDK 23 Initial Release Candidates are fast approaching, i.e., August 8th [3]! So, and in addition to testing your projects with the latest JDK 23 early-access builds, it is now a good time to start testing with the JDK 24 early-access builds. Make sure to also check the heads-up below as some are related to JDK 23 and might have some impact, i.e., the first one being related to the eventual removal of the Security Manager and the second one discusses the removal of the legacy COMPAT locale provider. [1] https://mail.openjdk.org/pipermail/jdk-dev/2024-July/009252.html [2] https://openjdk.org/jeps/3#rdp-2 [3] https://openjdk.org/projects/jdk/23/ ## Heads-up - JDK 23: Subject.getSubject API Requires Allowing the Security Manager In JDK 17 and as announced in JEP 411 [4], the Security Manager was deprecated for removal. As part of that change, several Security Manager APIs, such as `AccessControlContext`, were deprecated for removal. The `Subject::doAs` and `Subject::getSubject` APIs depend on Security Manager related APIs even though they do not require Security Manager to be installed to use them. As of JDK 23 [5], to help applications prepare for the eventual removal of the Security Manager, subject authorization and the Subject APIs' behavior depend on allowing the Security Manager: - If the system property `java.security.manager` is set on the command line to the empty string, a class name, or the value `allow` then there is no behavior change compared to previous releases. - If the system property `java.security.manager` is not set on the command line or has been set on the command line to the value `disallow`, invoking the `Subject.getSubject` method will throw `UnsupportedOperationException`. Yet, running an application with `-Djava.security.manager=allow` is a temporary workaround to keep older code working. Maintainers of code using `Subject.doAs` and `Subject.getSubject` are strongly encouraged to migrate it with utmost priority to the replacement APIs, `Subject.callAs` and `Subject.current`. Make sure to check [5] and [6] for additional details. The jdeprscan tool [7] scans a JAR file for usage of deprecated API elements and is helpful to find code using these methods. Additionally, consider migrating as soon as possible code that stores a `Subject` in an `AccessControlContext` and invokes `AccessController.doPrivileged` with that context. Such code will stop working when the Security Manager is removed. [4] https://openjdk.org/jeps/411 [5] https://jdk.java.net/23/release-notes#b15 [6] https://inside.java/2024/07/08/quality-heads-up/ [7] https://dev.java/learn/jvm/tools/core/jdeprscan/ ## Heads-up - JDK 23: Unicode / Removal of COMPAT Locale Provider ### A Quick History of Locale Data in the JDK Before the Unicode Consortium created the Common Locale Data Repository (CLDR) in 2003 to manage locale data, the JDK had to provide its own collection. It did so successfully and in JDK 8 supported about 160 locales. To reduce maintenance effort, allow better interoperability between platforms, and improve locale data quality, the JDK started to move towards CLDR in 2014: - JDK 8 comes with two locale data providers, which can be selected with the system property java.locale.providers: . JRE/COMPAT for the JDK’s legacy data collection (default) . CLDR for the CLDR data . a custom locale provider can be implemented - JDK 9 picks CLDR by default - JDK 21 issues a warning on JRE/COMPAT There are plenty of minor and a few notable differences between the legacy data and CLDR - the recently rewritten JEP 252 [8] lists a few of them. ### Locale Data in JDK 23 JDK 23 [9] removes legacy locale data. As a consequence, setting java.locale.providers to JRE or COMPAT has no effect. Projects that are still using legacy locale data are highly encouraged to switch to CLDR as soon as possible. Where that is infeasible, two alternatives remain: - Create custom formatters with patterns that mimic the legacy behavior and use them everywhere where locale-sensitive data is written or parsed. - Implement a custom locale data provider [10]. For more details on that as well as on CLDR in the JDK in general, please check JEP 252 [8] that has been recently rewritten to provide better information and guidance. [8] https://openjdk.org/jeps/252 [9] https://bugs.openjdk.org/browse/JDK-8325568 [10] https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/spi/LocaleServiceProvider.html ## Heads-up - JDK 23: Initial Leyden Early-Access Builds Project Leyden published its first
JDK 23 Release Candidates | Restrictive JAXP Configuration Heads-up
Welcome to the latest OpenJDK Quality Outreach update!
Everything is on track for the General Availability of Java 23 on September
17th [1] as the JDK 23 Release Candidate builds (RC2 - builds 37) are now
available [2]. And before shifting your attention to JDK 24, make sure to check
the Heads-Up below as it is related to an important JAXP update in JDK 23.
The JVM Language Summit took place earlier this month in Santa Clara
(California). During this unique conference, key updates around the Java
platforms were presented and discussed. So, make sure to watch the JVMLS 2024
playlist [3] as videos are added regularly. And it's not really a surprise but
Valhalla was a highly discussed topic. In his session [4], Brian Goetz (Java
Language Architect) explained the proposed solution: value classes,
null-restricted types, improved definite assignment analysis, and strict
initialization. Around the same time-frame, Valhalla Early-Access builds
implementing Value Classes and Objects were also made available [5], see the
Release Notes [6] for the details. As usual, feedback should be reported to the
proper mailing list [7].
[1] https://openjdk.org/projects/jdk/23/
[2] https://jdk.java.net/23/
[3] https://www.youtube.com/playlist?list=PLX8CzqL3ArzUEYnTa6KYORRbP3nhsK0L1
[4] https://www.youtube.com/watch?v=IF9l8fYfSnI
[5] https://jdk.java.net/valhalla/
[6] https://openjdk.org/projects/valhalla/early-access
[7] https://mail.openjdk.org/mailman/listinfo/valhalla-dev
## Heads-up - JDK 23: Prepare for a More Restrictive JAXP Configuration
The Java platform supports XML processing with JAXP (Java APIs for XML
Processing) that are based on a wide range of XML technologies and standards,
which can make them challenging to secure. To mitigate risks, JAXP offers
comprehensive security features [8], but the default settings of some security
features are not strict, making them opt-in. To improve out-of-the-box
security, future JDK releases will make XML processing more restrictive by
default and JDKs 21 to 23 help developers prepare for these changes.
### JDK 21: JAXP Configuration File
JDK 21 added `$JAVA_HOME/conf/jaxp.properties` as the default JAXP
configuration file, property settings in this file reflect the current,
built-in defaults for the JDK. JDK 21 also added the system property
`java.xml.config.file` for specifying the location of a custom configuration
file. For details, refer to JDK-8303530 [9] or the `java.xml` documentation
[10].
### JDK 23: Restrictive JAXP Configuration File Template
JDK 23 adds `$JAVA_HOME/conf/jaxp-strict.properties.template`, a JAXP
configuration file template that specifies more restrictive XML processing
settings. It is recommended to test applications on these more restrictive
settings to prepare them for a future JDK release that has them as default.
The following steps should be used to test an application with that template:
* copy the template file to a location outside of `$JAVA_HOME/conf`, e.g.
`//jaxp-strict.properties`
* run the application with the system property `java.xml.config.file` set to
the file's path, e.g. `java
-Djava.xml.config.file=//jaxp-strict.properties myApp`
For details, please refer to JDK-8330542 [11].
[8]
https://docs.oracle.com/en/java/javase/22/security/java-api-xml-processing-jaxp-security-guide.html#GUID-6E76FE41-A8C5-4F56-AB46-83A89B1E904A
[9] https://bugs.openjdk.org/browse/JDK-8303530
[10]
https://docs.oracle.com/en/java/javase/21/docs/api/java.xml/module-summary.html#Conf
[11] https://bugs.openjdk.org/browse/JDK-8330542
## JDK 24 Early-Access Builds
The JDK 24 early-access builds 12 are available [12], and are provided under
the GNU General Public License v2, with the Classpath Exception. The Release
Notes are available here [13].
### Changes in recent JDK 24 builds that may be of interest:
- JDK-8335638: Calling VarHandle.{access-mode} methods reflectively throws
wrong exception
- JDK-8329471: Remove GTK2
- JDK-8333772: Incorrect Kerberos behavior when udp_preference_limit = 0
- JDK-8304929: MethodTypeDesc throws an unchecked exception than
ReflectiveOperationException …
- JDK-4966250: SSLSessionContext.setSessionTimeout() documentation could be
updated
- JDK-8337506: Disable "best-fit" mapping on Windows command line
- JDK-8336479: Provide Process.waitFor(Duration)
- JDK-8336999: Verification for resource area allocated data structures in C2
- JDK-8335480: Only deoptimize threads if needed when closing shared arena
- JDK-8335939: Hide element writing across the ClassFile API
- JDK-8336489: Track scoped accesses in JVMCI compiled code
- JDK-8334492: DiagnosticCommands (jcmd) should accept %p in output filenames
and substitute PID
- JDK-8334495: Use FFM instead of jdk.internal.misc.Unsafe in java.desktop font
implementation
- JDK-896: Use StringBuilder internally for java.text.Format.* formatting
- JDK-8336815: Several methods in java.net.Socket and ServerSocket do not s…
Note: A more exhaus
OpenJDK Quality Outreach: JDK 23 is GA, JDK 24 EA builds
Welcome to the latest OpenJDK Quality Outreach update. JDK 23 was released last month as planned. You can find "The Arrival of Java 23" announcement here [1], and some additional Java 23 materials in the "Topics of Interest" section at the bottom of this update. You can also rewatch the Java 23 launch stream here [2]. Thank you to all the projects who contributed to this release by testing the early-access builds and by providing feedback and or identifying issues. Through your participation in this program, you are helping to shape the Java platform! Let's now shift our attention to JDK 24 which will enter the Rampdown Phase in less than 6 weeks on December 5th [3]. [1] https://inside.java/2024/09/17/jdk-23-available/ [2] https://www.youtube.com/live/QG9xKpgwOI4?feature=shared [3] https://openjdk.org/projects/jdk/24/ ## JDK 24 The JDK 24 early-access builds 21 are available [4], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [5]. As of the time of writing, the following JEPs have been targeted to JDK 24 - JEP 472: Prepare to Restrict the Use of JNI - JEP 475: Late Barrier Expansion for G1 - JEP 485: Stream Gatherers - JEP 484: Class-File API - JEP 489: Vector API (9th Incubator) while the following JEPs have been proposed to target JDK 24 - JEP 404: Generational Shenandoah (Experimental) - JEP 478: Key Derivation Function API (Preview) - JEP 487: Scoped Values (4th Preview) - JEP 490: ZGC: Remove the Non-Generational Mode ### Changes in recent JDK 24 builds that may be of interest: - JDK-8337302: Undefined type variable results in null - Reported & fixed by ByteBuddy - JDK-8338406: BytecodeHelpers using wrong bootstrap method descriptor for condy - Reported by ByteBuddy - JDK-8338623: StackCounter adding extraneous slots for receiver invoke instructions - Reported by ByteBuddy - JDK-8338661: StackMapTable is invalid if frames appear in dead code - Reported by ByteBuddy - JDK-8338745: Intrinsify Continuation.pin() and Continuation.unpin() - JDK-8338979: Avoid bootstrapped switches in the classfile API - JDK-8338939: Simplify processing of hidden class names - JDK-8335288: SunPKCS11 initialization will call C_GetMechanismInfo on unsupported mechanisms - JDK-8286851: Deprecate for removal several of the undocumented java launcher options - JDK-8337664: Distrust TLS server certificates issued after Oct 2024 and anchored by Entrust Root CAs - JDK-8338936: StringConcatFactory optimize the construction of MethodType and MethodTypeDesc - JDK-8339918: Remove checks for outdated -t -tm -Xfuture -checksource -cs -noasyncgc options from … - JDK-8328608: Multiple NewSessionTicket support for TLS - JDK-8338890: Add monitoring/management interface for the virtual thread scheduler - JDK-8338731: MemoryLayout::offsetHandle can return a negative offset - JDK-8325679: Optimize ArrayList subList sort - JDK-8338947: Deprecate the UseLinuxPosixThreadCPUClocks flag and remove it in a future release - JDK-8338700: AttributeMapper type parameter should be bounded by Attribute - JDK-8339214: Remove misleading CodeBuilder.loadConstant(Opcode, ConstantDesc) - JDK-8336492: Regression in lambda serialization - JDK-8328877: [JNI] The JNI Specification needs to address the limitations of integer UTF-8 String lengths - JDK-8338894: Deprecate jhsdb debugd for removal - JDK-8334870: javac does not accept classfiles with certain permitted RuntimeVisibleParameterAnnotations… - JDK-8334165: Remove serialVersionUID compatibility logic from JMX Note: A complete list of changes can be found here [6]. [4] https://jdk.java.net/24/ [5] https://jdk.java.net/24/release-notes [6] https://github.com/openjdk/jdk/compare/jdk-24+12...jdk-24+21 ## JavaFX 24 Early-Access Builds These are early access builds of the JavaFX 24 Runtime built from openjdk/jfx. These builds enable JavaFX application developers to build and test their applications with JavaFX 24 on JDK 24. Although these builds are designed to work with JDK 24-ea, they are also known to work with JDK 22 and later versions. The latest early access builds of JavaFX 24 Builds 14 (2024/10/18) are available [7], under the GNU General Public License, version 2, with the Classpath Exception. JavaFX 24 API Javadocs [8] are available too. [7] https://jdk.java.net/javafx24/ [8] https://download.java.net/java/early_access/javafx24/docs/api/overview-summary.html ## Topics of Interest - JDK 23 Security Enhancements https://seanjmullan.org/blog/2024/09/17/jdk23 - Java 23 - Better Language, Better APIs, Better Runtime https://inside.java/2024/09/26/javazone-java23/ - Reviewing the JDK 23 Release Notes https://inside.java/2024/09/19/newscast-76/ - JEP 14: The Tip & Tail Model of Library Development https://openjdk.org/jeps/14 - New Loom Early-Access Builds with Changes for JDK 24 https://mail.openjdk.org/pipermail/loom-dev/2024-September/007166.html - JVMLS: Loom - Where Are We? https://in
JDK 24 Release Candidate | JavaOne and More Heads-Up
Welcome to the first OpenJDK Quality Outreach update of 2025! The first Release Candidate builds of JDK 24 are now available [1] and tt this stage, only P1 issues will be evaluated. With the JDK 24 General Availability set for March 18th, the attention is now turning to JDK 25. JDK 24 will officially launch at JavaOne in Redwood Shores, CA [2]. If you're attending or planning to attend JavaOne, please reach out as I’m planning a Quality Outreach gathering. To conclude, make sure to take a look at the heads-up below. [1] https://jdk.java.net/24/ [2] https://javaone.com/ # Heads-up - JDK 24: Remote Debugging with `jstat` and `jhsdb` is Deprecated for Removal Java's Remote Method Invocation (RMI), introduced in 1997, enables remote procedure calls between different JVMs. RMI relies on serialization to encode objects into byte streams when sending them as arguments and return values between JVMs. Both technologies have long-term security issues and configuration challenges, and they haven't withstood the test of time. Today, the broader ecosystem has moved away from RMI in favor of more web-friendly protocols, and as a result, Java is also gradually reducing and eliminating its dependencies on it where possilbe. Among other tools, Java offers these two tools to connect to a local HotSpot JVM and observe or debug it as well as the program it executes: - `jstat` reads performance counters - `jhsdb` provides snapshot debugging and analysis features Both `jstat` and `jhsdb` offer remote capabilities, which are implemented using RMI. Due to the aforementioned effort to reduce dependencies on RMI, the remote capabilities of `jstat` and `jhsdb` are deprecated for removal in JDK 24: - JDK-8327793 [3]: `jstatd` allows remote connections with jstat - JDK-8338894 [4]: `jhsdb debugd` (allows remote connections with `jhsdb`) as well as the `--connect` option of the `jhsdb` subcommands `hsdb` and `clhsdb` Please note that `jstat` and `jhsdb`'s capabilities for local use remain available and there are no plans to change that. It should also be mentionned that JFR (JDK Flight Recorder) offers a modern alternative for getting remote insights into a running HotSpot JVM. Questions or feedback on these deprecations can be directed at the serviceability-dev mailing list [5] (subscription required). [3] https://bugs.openjdk.org/browse/JDK-8327793 [4] https://bugs.openjdk.org/browse/JDK-8338894 [5] https://mail.openjdk.org/mailman/listinfo/serviceability-dev # Heads-up - JDK 25: Proposal to Deprecate for Removal `-UseCompressedClassPointers` ## Reducing Code and Test Complexity Shortly after the adoption of 64-bit architectures the `-XX:[-|+]UseCompressedClassPointers` and `-XX:[-|+]UseCompressedOops` arguments were added to provide Java users the ability to enable using 32-bit references even when on a 64-bit architecture. This reduces memory overhead and helps reduce cache misses. You can read more about this here [6]. Removing the `-UseCompressedClassPointers` option would make `+UseCompressedClassPointers` the default case and reduce the number of configurations that would need to be supported from three to two (`+UseCompressedClassPointers` and `+UseCompactObjectHeaders`). This would also significantly reduce code complexity as well as testing effort. Along with this, `-UseCompressedClassPointers` does not work well in a 64-bit architecture as can be seen here [7], it’s suspected there are many more examples. ## Minimal Benefit The `-UseCompressedClassPointers` use rarely provides any tangible benefit to Java users. Any historical connection with the `-UseCompresseedOops`flag has long since been removed, and the net result of using `-UseCompressedClassPointers` is simply increased memory overhead. ## Reasons to Keep `-UseCompressedClassPointers` There are currently two reasons to continue supporting `-UseCompressedClassPointers`: - `-UseCompressedClassPointers` works well in 32-bit operating systems. However support for 32-bit operating systems is on its way out with JEP 479: 'Remove the Windows 32-bit x86 Port' [8] and JEP 501: 'Deprecate the 32-bit x86 Port for Removal' [9] which are both in forthcoming JDK 24. - In cases where more than 5 million classes are loaded. However such cases are rare, likely the result of programmer error, and would also mean loading likely tens of GBs of non-class data into metaspace as well. For more on this topic, check this thread [10] on the hotspot-dev mailing list. The engineers working on this are considering marking `-UseCompressedClassPointers` as deprecated for removal in JDK 25 and are looking for feedback on the impact this could have. Please direct questions and feedback to the lilliput-dev [11] mailing list (registration required). [6] https://stuefe.de/posts/metaspace/what-is-compressed-class-space/ [7] https://github.com/openjdk/jdk/pull/23053 [8] https://openjdk.org/jeps/479 [9] https://openjdk.org/jeps/501 [10]
JDK 24 Feature Freeze | Permanently Disabling the Security Manager
Welcome to the final OpenJDK Quality Outreach update of 2024! JDK 24, scheduled for General Availability on March 18, 2025 [1], is now in Rampdown Phase One (RDP1) [2]. At this point, the overall JDK 24 feature set is frozen and only low-risk enhancements might still be considered. You will find below the final list of the 24 JEPs that were integrated into JDK 24 as well as JDK 24 technical materials in the last section. This QO update also covers 3 important heads-ups related to security, integrity and JDK 24. The next key milestone is early February with the first JDK 24 Release Candidate builds. That means that we have a few weeks, modulo the end of year break, to find and hopefully address any issue that your projects might encounter. So, please let us know if you encounter any issue with the JDK early-access builds. [1] https://openjdk.org/projects/jdk/24/ [2] https://mail.openjdk.org/pipermail/jdk-dev/2024-December/009672.html # Heads-up - JDK 24: Permanently Disabling the Security Manager Introduced to enforce the principle of the least privilege, the Security Manager was designed to prevent unauthorized code from accessing sensitive resources (ex. files, network connections, etc.). While effective in theory, it has fallen short in practice for multiple reasons: complexity, limited adoption, maintenance overhead and evolving threat landscape. In Java 17, the Security Manager was deprecated for removal under JEP 411 [3]. In JDK 24, its functionality will be effectively disabled via JEP 486 [4]. Key changes include: - Disabling the Security Manager - it will no longer be possible to enable the SM at startup using command-line options, nor will it be possible to install a custom SM during runtime. - Rendering the Security Manager API non-functional - the SM API will remain present for compatibility but will no longer have any operational effect. - Improving maintainability - thousands of lines of code dedicated to supporting the Security Manager will be removed, freeing OpenJDK contributors to implement modern security features. Developers and enterprises using older Java versions or legacy applications relying on the Security Manager will retain access until JDK 24. Beyond that, they are encouraged to transition to alternative sandboxing and API interception mechanisms. ## Call to Action The deprecation of the Security Manager in JDK 17 had little to no impact on most Java developers. Warnings issued in JDK 17–23 generated minimal discussion in the Java ecosystem, highlighting its limited relevance. Furthermore, major frameworks and tools (ex. Jakarta EE, Ant, Tomcat, etc.) have already removed support for the Security Manager, reinforcing the trend. For applications still dependent on the Security Manager, the JDK offers options to identify and address its usage: - jdeprscan [5] scans a JAR file for the usage of deprecated API elements, and it helps find code using these methods. - Messages on the console warnings highlight Security Manager usage during runtime. - Check how you launch your Java application - with the Security Manager allowed or enabled via command line options, or policy files that require it to be installed and configured. These tools give code maintainers the necessary insights to transition away from the Security Manager before its complete removal in future JDK releases. By taking these steps, you will ensure a smooth transition from the Security Manager while adopting more effective security practices. This is a summary; for more details, make sure to read JEP 486 [4]. [3] https://openjdk.org/jeps/411 [4] https://openjdk.org/jeps/486 [5] https://dev.java/learn/jvm/tools/core/jdeprscan/ # Heads-up - JDK 24: Prepares Restricted Native Access Any interaction between Java code and native code, be it via the Java Native Interface (JNI) API or the Foreign Function & Memory (FFM) API, is risky in the sense that it can compromise the integrity of applications and of the Java Platform itself, for example by causing JVM crashes, even after the native code completed execution. According to the policy of integrity by default, all JDK features that are capable of breaking integrity must obtain explicit approval from the application’s developer. JDK 24, by means of JEP 472 [6], prepares that by aligning the behaviors of JNI and FFM by: - Printing warnings for all restricted operations (with the goal to turn these into exceptions in a future release). - Expanding the command-line options `--enable-native-access` and `--illegal-native-access` to govern restricted operations of both APIs. Note that this is a change for JNI, which used to not trigger such warnings, as well as for FFM, which used to forbid restricted operations by default. Starting with JDK 24, both APIs behave uniformly by printing warnings. In the future, both APIs will throw exceptions instead. The intent is neither to discourage the use of, deprecate, or eve
OpenJDK Quality Outreach: Java 24 Is Now Available!
Greetings and welcome to the latest OpenJDK Quality Outreach update!
JDK 24 was officially released (General Availability) on March 18th during
JavaOne. You can rewatch the Java 24 launch and the J1 keynote here [1]. Be
sure to also check out the Quality Outreach section here [2]. JavaOne was
amazing, and if you couldn't attend, make sure to watch the JavaOne 2025
playlist [3] regularly as sessions are gradually being added.
With the release of JDK 24, the focus now moves to JDK 25 testing. On that
note, be sure to check out the heads-up below, with more to follow. And as
always, if you experience any issues with your project running on a JDK 25
early-access builds, please don't hesitate to reach out.
[1] https://www.youtube.com/watch?v=mk_2MIWxLI0&t=12s
[2] https://www.youtube.com/live/GwR7Gvi80Xo?si=gxdqAhVbnNV0JZGt&t=2795
[3] https://www.youtube.com/playlist?list=PLX8CzqL3ArzVV1xRJkRbcM2tOgVwytJAi
# Heads-up - JDK 25: New Null Checks in Inner Class Constructors
The Java Language Specification prescribes that various use sites of inner
class constructors should include null checks of the immediately enclosing
instance and from then on assumes that the reference is non-null. However, it
does not mandate such checks of the incoming instance at the declaration site
of these constructors and so core reflection, method handles, and direct
bytecode invocation can pass null as enclosing instance, which can lead to
NullPointerExceptions down the road.
Since a null enclosing instance is outside of the JLS and the future evolution
of inner classes may lead to unexpected NPEs, Java 25 will start ensuring that
references to the immediately enclosing instance are always non-null.
Starting with JDK 25, when javac is targeting release 25 or higher, it will
emit null checks for the enclosing instances in inner class constructors.
This behavioral change will lead to new NPEs in code that uses core reflection,
method handles, or direct bytecode invocation to pass null as enclosing
instance. Such code is rare and usually found in libraries or frameworks (as
opposed to in applications). It should be changed to no longer pass a null
reference.
In case these additional checks lead to issues, their emission can be prevented
with a flag: `-XDnullCheckOuterThis=(true|false)`. This should be seen as a
temporary workaround and no guarantees are made for how long this flag will be
available.
For more details, check JDK-8351274 [4].
[4] https://bugs.openjdk.org/browse/JDK-8351274
# JDK 25
The JDK 25 early-access builds 17 are available [5] and are provided under the
GNU General Public License v2, with the Classpath Exception. The Release Notes
are available here [6].
The following JEPs have been targeted to JDK 25, so far:
- JEP 502: Stable Values (Preview)
- JEP 503: Remove the 32-bit x86 Port
## Changes in recent JDK 25 builds that may be of interest:
- JDK-8353118: Deprecate the use of `java.locale.useOldISOCodes` system property
- JDK-8351435: Change the default Console implementation back to the built-in
one in `java.base` module
- JDK-8350459: MontgomeryIntegerPolynomialP256 multiply intrinsic with AVX2 on
x86_64
- JDK-8349583: Add mechanism to disable signature schemes based on their TLS
scope
- JDK-8338675: javac shouldn't silently change .jar files on the classpath
- JDK-8319447: Improve performance of delayed task handling
- JDK-8341775: Duplicate manifest files are removed by jarsigner after signing
- JDK-8303770: Remove Baltimore root certificate expiring in May 2025
- JDK-8346948: Update CLDR to Version 47.0
- JDK-8348829: Remove ObjectMonitor perf counters
- JDK-8164714: Constructor.newInstance creates instance of inner class with
null outer class
- JDK-8352716: (tz) Update Timezone Data to 2025b
- JDK-8347946: Add API note that caller should validate/trust signers to the
getCertificates and getCodeSigners methods of JarEntry and JarURLConnection
- JDK-8345213: JVM Prefers /etc/timezone Over /etc/localtime on Debian 12
- JDK-8350646: Calendar.Builder.build() Throws ArrayIndexOutOfBoundsException
- JDK-8347433: Deprecate XML interchange in
java.management/javax/management/modelmbean/DescriptorSupport for removal
- JDK-8328119: Support HKDF in SunPKCS11 (Preview)
- JDK-8327378: XMLStreamReader throws EOFException instead of XMLStreamException
- JDK-8024695: new File("").exists() returns false whereas it is the current
working directory
- JDK-8351224: Deprecate com.sun.tools.attach.AttachPermission for removal
- JDK-8351310: Deprecate com.sun.jdi.JDIPermission for removal
- JDK-8348561: Add aarch64 intrinsics for ML-DSA
- JDK-8351266: JFR: -XX:StartFlightRecording:report-on-exit
- JDK-8350638: Make keyboard navigation more usable in API docs
- JDK-8350464: The flags to set the native priority for the VMThread and Java
threads need a broader range
- JDK-8349860: Make Class.isArray(), Class.isInterface() and
Class.isPrimitive() non-native
- JDK-8347335: ZGC: Use limitless m
