[Jython-dev] JDK 24 Release Candidate | JavaOne and More Heads-Up

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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] https://mail.openjdk.org/pipermail/hotspot-dev/2025-February/101023.html
[11] https://mail.openjdk.org/pipermail/lilliput-dev/

# Heads-Up - Distrust New TLS Server Certificates Issued by Camerfirma Root Certificates

The Java Cryptographic Roadmap has been updated to reflect how the JDK will stop trusting new TLS server certificates issued by Camerfirma, aligning with similar actions taken by Apple, Google, Microsoft, and Mozilla. In short, TLS Server certificates issued on or before April 15, 2025 will continue to be trusted until they expire while new certificates issued after that date will be rejected. JDK 24 will be one of the many versions affected by this change. For more details, please check the latest Java Cryptographic Roadmap [12].

[12] https://www.java.com/en/jre-jdk-cryptoroadmap.html

# Heads-Up - JavaFX Metal Early-Access builds

Early access builds of JavaFX that implement the new macOS Metal graphics rendering pipeline are now available [13]. These EA builds are provided as a convenience, so users don't have to build from the "metal" branch of the openjdk/jfx-sandbox repository [14]. The goal of these early access builds is to gather feedback as the team works on incorporating this feature into JavaFX. Feedback can be reported to the openjfx-dev mailing list [15] (subscription required). These builds are based on an incomplete version of JavaFX 25.

Moreover, the initial JavaFX 25 early-access builds are now also available [16].

[13] https://jdk.java.net/javafxmetal/
[14] https://github.com/openjdk/jfx-sandbox/tree/metal
[15] https://mail.openjdk.org/pipermail/openjfx-dev/
[16] https://jdk.java.net/javafx25/

# JDK 24 Release Candidates

The JDK 24 Release Candidate builds (builds 36) are available [17] and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [18], and the javadocs here [19].

[17] https://jdk.java.net/24/
[18] https://jdk.java.net/24/release-notes
[19] https://download.java.net/java/early_access/jdk24/docs/api/

# JDK 25 Early-Access Builds

The JDK 25 early-access builds 9 are now available [20] and are provided under the GNU General Public License v2, with the Classpath Exception. The initial Release Notes are available here [21].

## Changes in recent JDK 25 builds that may be of interest:
- JDK-8347949: Currency method to stream available Currencies
- JDK-8344168: Change Unsafe base offset from int to long
- JDK-8347506: Compatible OCSP readtimeout property with OCSP timeout
- JDK-8346587: Distrust TLS server certificates anchored by Camerfirma Root CAs
- JDK-8345045: Remove the jmx.remote.x.buffer.size JMX notification property
- JDK-8345049: Remove the jmx.tabular.data.hash.map compatibility property
- JDK-8344976: Remove the jmx.invoke.getters compatibility property
- JDK-8345048: Remove the jmx.extend.open.types compatibility property
- JDK-8328919: Add BodyHandlers / BodySubscribers methods to handle excessive server input
- JDK-8344966: Remove the allowNonPublic MBean compatibility property
- JDK-8347596: Update HSS/LMS public key encoding
- JDK-8283795: Add TLSv1.3 and CNSA 1.0 algorithms to implementation requirements
- JDK-8225763: Inflater and Deflater should implement AutoCloseable
- JDK-8345432: (ch, fs) Replace anonymous Thread with InnocuousThread
- JDK-8345259: Disallow ALL-MODULE-PATH without explicit --module-path
- JDK-8335428: `ProcessBuilder` on Windows Quotes Argument Strings Containing Any Space Character
- JDK-8287788: Implement a better allocator for downcalls
- JDK-8344137: Update XML Security for Java to 3.0.5
- JDK-8334581: Remove no-arg constructor BasicSliderUI()
- JDK-8347965: (tz) Update Timezone Data to 2025a

Note: A complete list of changes can be found here [22].

[20] https://jdk.java.net/25/
[21] https://jdk.java.net/25/release-notes
[22] https://github.com/openjdk/jdk/compare/jdk-25+1...jdk-25+9

# Topics of Interest

Java Language Evolution in 2025
https://inside.java/2025/01/30/newscast-84/

Java's Plans for 2025
https://inside.java/2025/01/16/newscast-83/

A Deep Dive into JVM Start-up
https://inside.java/2025/01/28/jvm-start-up/

Modern Java Deep Dive
https://inside.java/2025/02/09/devoxxbelgium-modern-java-deepdive/

Java Performance Update
https://inside.java/2025/01/26/devoxxbelgium-java-perfromance-update/

Podcast - “Doc, JavaDoc and Markdown” with Jonathan Gibbons
https://inside.java/2025/01/21/podcast-034/

Evolution of Java Ecosystem for Integrating AI
https://inside.java/2025/01/29/evolution-of-java-ecosystem-for-integrating-ai/

Peaceful and Bright Future of Integrity by Default in Java
https://inside.java/2025/01/03/evolving-default-integrity/

James Gosling on Java - Historical Oddities & Persistent Itches #JVMLS
https://inside.java/2024/12/28/jvmls-jamesgosling/

~

I’d like to thank everyone who has already provided feedback on the JDK 25 builds. Your input is incredibly valuable, especially when received early in the development cycle. And if you encounter any issues, please ping me.

Hope to see some of you at JavaOne!

--David