[hibernate-dev] JDK 23 Feature Freeze / New Loom EA builds
Welcome to the latest OpenJDK Quality Outreach update! JDK 23, scheduled for General Availability on September 17, 2024, is now in Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 23 feature set is frozen (see the final list of JEPs integrated into JDK 23 below) and only low-risk enhancements might still be considered. The coming weeks should be leveraged to identify and resolve as many issues as possible, i.e. before JDK 23 enters the Release Candidates phase in early August [2]. We count on you to test your projects and help us make JDK 23 another solid release! This time, we are covering several heads-up related to JDK 23 : Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal and default annotation processing policy change. Also, make sure to check the new Loom early-access builds which have an improved Java monitors implementation to work better with virtual threads. [1] https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009053.html [2] https://openjdk.org/projects/jdk/23/ ## Heads-Up - JDK 23: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal As mentioned in a previous communication [3], there’s a plan to ultimately remove the sun.misc.Unsafe memory-access methods as the platform offers safer alternatives. JEP 471 (Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal) [4] outlines in more detail this plan including the initial step which is happening in JDK 23, i.e., all of the sun.misc unsafe memory-access methods are now marked as deprecated for removal. This will cause, in JDK 23, compile-time deprecation warnings for code that refers to these methods, alerting library developers to their forthcoming removal. A new command-line option also enables application developers and users to receive runtime warnings when those methods are used. Developers relying on those sun.misc.Unsafe APIs for access memory are strongly encouraged to start, if they haven't done so yet, the migration from the sun.misc.Unsafe APIs to supported replacements. For more details, make sure to read JEP 471 (Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal). [3] https://mail.openjdk.org/pipermail/quality-discuss/2024-January/001132.html [4] https://openjdk.org/jeps/471 ## Heads-Up - JDK 23: Changes Default Annotation Processing Policy Annotation processing is a compile-time feature, where javac scans the to-be-compiled source files for annotations and then the class path for matching annotation processors, so they can generate source code. Up to JDK 22, this feature is enabled by default, which may have been reasonable when it was introduced in JDK 6 circa 2006, but from a current perspective, in the interest of making build output more robust against annotation processors being placed on the class path unintentionally, this is much less reasonable. Hence, starting with JDK 23, javac requires an additional command-line option to enable annotation processing. ### New `-proc` Value To that end, the pre-existing option `-proc:$policy` was extended, where `$policy` can now have the following values: - `none`: compilation _without_ annotation processing, this policy exists since JDK 6 - `only`: annotation processing _without_ compilation, this policy exists since JDK 6 - `full`: annotation processing followed by compilation, this policy is the default in JDK ≤22 but the value itself is new (see next section for versions that support it) Up to and including JDK 22, code bases that require annotation processing before compilation could rely on javac's default behavior to process annotations but that is no longer the case. Starting with JDK 23, at least one annotation-processing command line option needs to be present. If neither `-processor`, `--processor-path`, now `--processor-module-path` is used, `-proc:only` or `-proc:full` has to be provided. In other words, absent other command line options, `-proc:none` is the default on JDK 23. ### Migration to `-proc:full` Several measures were undertaken to help projects prepare for the switch to `-proc:full`: - As of the April 2024 JDK security updates, support for `-proc:full` has been backported to 17u (17.0.11) and 11u (11.0.23) for both Oracle JDK and OpenJDK distributions. Additionally, Oracle's 8u release (8u411) also supports `-proc:full`. - Starting in JDK 21, javac prints an informative message if implicit usage of annotation processing under the default policy is detected. With `-proc:full` backported, it is possible to configure a build that will work the same before and after the change in javac's default policy. Additional details can be found in the original proposal [5]. [5] https://mail.openjdk.org/pipermail/jdk-dev/2024-May/009028.html ## Heads-up - Loom: New EA builds with improved Java monitors implementation to work better with virtual threads Project Loom published new early-access builds [6]. These builds have an improved
[hibernate-dev] Re: [External] : Re: JDK 23 Feature Freeze / New Loom EA builds
Great, thanks for update Yoann. --David From: Yoann Rodiere Date: Friday, 14 June 2024 at 10:10 To: David Delabassee Cc: Hibernate Subject: [External] : Re: [hibernate-dev] JDK 23 Feature Freeze / New Loom EA builds Hey David, Since it's been a while, I'll confirm all is well on Hibernate projects: Hibernate ORM: Version 6.6 tested against JDK 23 (EA 26) / 24 (EA 1). No problems to report. Hibernate Validator: Version 8.0 tested against JDK 23 (EA 26) / 24 (EA 1). No problems to report. Hibernate Search: Version 7.2 tested against JDK 23 (EA 26) / 24 (EA 1). No problems to report. Hibernate Reactive: Version 2.3 tested against JDK 23 (EA 26) / 24 (EA 1). No problems to report. Have a nice day, Yoann Rodière Hibernate Team yo...@hibernate.org<mailto:yo...@hibernate.org> On Mon, Jun 10, 2024 at 11:05 AM David Delabassee via hibernate-dev mailto:hibernate-dev@lists.jboss.org>> wrote: Welcome to the latest OpenJDK Quality Outreach update! JDK 23, scheduled for General Availability on September 17, 2024, is now in Rampdown Phase One (RDP1) [1]. At this point, the overall JDK 23 feature set is frozen (see the final list of JEPs integrated into JDK 23 below) and only low-risk enhancements might still be considered. The coming weeks should be leveraged to identify and resolve as many issues as possible, i.e. before JDK 23 enters the Release Candidates phase in early August [2]. We count on you to test your projects and help us make JDK 23 another solid release! This time, we are covering several heads-up related to JDK 23 : Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal and default annotation processing policy change. Also, make sure to check the new Loom early-access builds which have an improved Java monitors implementation to work better with virtual threads. [1] https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009053.html [2] https://openjdk.org/projects/jdk/23/ ## Heads-Up - JDK 23: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal As mentioned in a previous communication [3], there’s a plan to ultimately remove the sun.misc.Unsafe memory-access methods as the platform offers safer alternatives. JEP 471 (Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal) [4] outlines in more detail this plan including the initial step which is happening in JDK 23, i.e., all of the sun.misc unsafe memory-access methods are now marked as deprecated for removal. This will cause, in JDK 23, compile-time deprecation warnings for code that refers to these methods, alerting library developers to their forthcoming removal. A new command-line option also enables application developers and users to receive runtime warnings when those methods are used. Developers relying on those sun.misc.Unsafe APIs for access memory are strongly encouraged to start, if they haven't done so yet, the migration from the sun.misc.Unsafe APIs to supported replacements. For more details, make sure to read JEP 471 (Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal). [3] https://mail.openjdk.org/pipermail/quality-discuss/2024-January/001132.html [4] https://openjdk.org/jeps/471 ## Heads-Up - JDK 23: Changes Default Annotation Processing Policy Annotation processing is a compile-time feature, where javac scans the to-be-compiled source files for annotations and then the class path for matching annotation processors, so they can generate source code. Up to JDK 22, this feature is enabled by default, which may have been reasonable when it was introduced in JDK 6 circa 2006, but from a current perspective, in the interest of making build output more robust against annotation processors being placed on the class path unintentionally, this is much less reasonable. Hence, starting with JDK 23, javac requires an additional command-line option to enable annotation processing. ### New `-proc` Value To that end, the pre-existing option `-proc:$policy` was extended, where `$policy` can now have the following values: - `none`: compilation _without_ annotation processing, this policy exists since JDK 6 - `only`: annotation processing _without_ compilation, this policy exists since JDK 6 - `full`: annotation processing followed by compilation, this policy is the default in JDK ≤22 but the value itself is new (see next section for versions that support it) Up to and including JDK 22, code bases that require annotation processing before compilation could rely on javac's default behavior to process annotations but that is no longer the case. Starting with JDK 23, at least one annotation-processing command line option needs to be present. If neither `-processor`, `--processor-path`, now `--processor-module-path` is used, `-proc:only` or `-proc:full` has to be provided. In other words, absent other command line options, `-proc:none` is the default on JDK 23. ### Migration to `-proc:full` Several
[hibernate-dev] 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
[hibernate-dev] 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
[hibernate-dev] 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-8336492: Regression in lambda serialization - JDK-8286851: Deprecate for removal several of the undocumented java launcher options - JDK-8339918: Remove checks for outdated -t -tm -Xfuture -checksource -cs -noasyncgc options from … - JDK-8338890: Add monitoring/management interface for the virtual thread scheduler - JDK-8338700: AttributeMapper type parameter should be bounded by Attribute - JDK-8339214: Remove misleading CodeBuilder.loadConstant(Opcode, ConstantDesc) - JDK-8328877: [JNI] The JNI Specification needs to address the limitations of integer UTF-8 String lengths - JDK-8338731: MemoryLayout::offsetHandle can return a negative offset - JDK-8325679: Optimize ArrayList subList sort - 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-8338947: Deprecate the UseLinuxPosixThreadCPUClocks flag and remove it in a future release - JDK-8338894: Deprecate jhsdb debugd for removal - JDK-8334165: Remove serialVersionUID compatibility logic from JMX - JDK-8334870: javac does not accept classfiles with certain permitted RuntimeVisibleParameterAnnotations… - JDK-8328608: Multiple NewSessionTicket support for TLS 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://ins
[hibernate-dev] 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]
[hibernate-dev] 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-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-8351266: JFR: -XX:StartFlightRecording:report-on-exit
- JDK-8350638: Make keyboard navigation more usable in API docs
- JDK-8347335: ZGC: Use limitless m
