New CI machine preview
by Sanne Grinovero
You're all welcome to play with http://54.225.162.168/
however please keep these in mind:
- it's not the final machine: don't put too much effort in creating
nice build scripts as we'll reset it to clean state soon. We *might*
be able to store jobs defined so far, but we might choose not to.
- domain name should be coming: ci.hibernate.org ..not sure when, got
no replies so far from.
- authentication: just click on login, it will use OAuth2 to request
your identity via your GitHub account. Permissions to create new jobs,
edit existing jobs, run a build manually depend on your github account
be part of the Hibernate organization (or not, in which case you have
read only status)
At this stage I'd like to get a feeling if the hardware is powerful
enough, and also we need to select which other plugins we want to use,
I'm looking especially to:
- static analysis reports
- pull requests integration
both are relatively undefined, we can of course start simple and
improve later.. just checking this fits basic needs now.
Sanne
1 week, 5 days
Re: JDK 24 Release Candidate | JavaOne and More Heads-Up
by Christian Beikov
Hey David,
Thank you for the updates. Everything looking good on our end:
Hibernate ORM: Version 6.6 and 7.0 tested against JDK 23.0.2 / 24 (EA
36) / 25 (EA 10). No problems to report.
Hibernate Validator: Version 9.0 tested against JDK 23.0.2 / 24 (EA 36)
/ 25 (EA 10). No problems to report.
Hibernate Search: Version 7.2 tested against JDK 23.0.2 / 24 (EA 36) /
25 (EA 10). No problems to report.
Hibernate Reactive: Version 2.3 tested against JDK 23.0.2 / 24 (EA 36) /
25 (EA 10). No problems to report.
Have a nice weekend,
Yoann
Hibernate team
8 months, 2 weeks
JDK 24 Release Candidate | JavaOne and More Heads-Up
by David Delabassee
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-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-8347506: Compatible OCSP readtimeout property with OCSP timeout
- JDK-8346587: Distrust TLS server certificates anchored by Camerfirma Root CAs
- 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-8344137: Update XML Security for Java to 3.0.5
- JDK-8334581: Remove no-arg constructor BasicSliderUI()
- JDK-8335428: `ProcessBuilder` on Windows Quotes Argument Strings Containing Any Space Character
- JDK-8287788: Implement a better allocator for downcalls
- 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-integratin...
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!
8 months, 4 weeks
Hibernate Governance Model
by Yoann Rodiere
Hey all,
As the move to the Commonhaus Foundation is progressing, we need to start
thinking about complying with the foundation's requirements. Fortunately,
they are few, and they make a lot of sense.
A particularly important requirement is to publish various policies [1].
Most of these policies we already publish or can start publishing easily;
e.g. the code of conduct can be copied verbatim from Commonhaus' own code
of conduct. But we, at Hibernate, have one gaping hole: our governance
model.
We've been getting by for years with an "implicit" governance and
decision-making model, and it worked great. But:
1. If we want to join Commonhaus, the list of current project leaders, as
well as how they get their position, must be clear: they are responsible
for compliance with Commonhaus requirements and need to sign paperwork.
2. Our move to Commonhaus is, among other reasons, intended to provide
strong openness guarantees and to foster contribution. Both require clarity
on how exactly decisions are made.
So, *it's time to make our governance model explicit*. I submitted a pull
request [2] taking inspiration from the Commonhaus template [3].
*To anyone involved in a Hibernate project*, be it now or a long time ago,
be it just for one commit or full-time for years: *please have a look*,
comment if you disagree or find problems, and let us know if you agree,
with an approving review or a thumbs-up reaction on the main description.
This governance model can only make sense if all members agree with it, and
commit to complying with it. Ultimately, the decision will be up to
Hibernate team members, but the opinion/concerns of all contributors are
very important.
*The pull request: https://github.com/hibernate/hibernate.org/pull/231
<https://github.com/hibernate/hibernate.org/pull/231>*
Please keep the discussions on that pull request, that'll make things
easier to follow.
[1] https://github.com/commonhaus/foundation/blob/main/templates/README.md
[2] https://github.com/hibernate/hibernate.org/pull/231
[3]
https://github.com/commonhaus/foundation/blob/main/templates/GOVERNANCE.md
Thanks in advance,
Yoann Rodière
Hibernate team
9 months
