API differences in Hibernate ORM 5.1 vs 5.3
by Gail Badner
Hi,
There were lots of differences in the compatibility report, so as a first
step, I've excluded packages/classes that I considered SPI, internal, or
"grey area". This reduced the the differences to a more manageable amount.
You can see a summary of the incompatibilities along with suggested
mitigation at [1].
The report is attached to [1], along with a zip with instructions for
running the report.
I believe there are some "false positives" in the report, and I have
documented them in the section, "False Positives?".
Feel free to comment on the article.
Thanks,
Gail
[1]
https://developer.jboss.org/wiki/HibernateORMBinaryCompatibilityBetween51...
2 days
IP banned from forum
by Gunnar Morling
Hi,
Is anyone banning users from the forum? I am getting "A ban has been
issued on your IP address."
I don't think banning by IP is a good strategy as many users will have
dynamic IPs from their hoster's shared pool, so it's a random game to
hit an IP previously banned due to some other user's spam.
Thanks,
--Gunnar
2 days, 6 hours
New annotation for nullable string validation
by Ivan
Hello team,
I've observed an inconsistency in the default validation behavior that
affects the validation of nullable fields.
As documented, most constraints in the `jakarta.validation.constraints`
package (with the exception of `@Null`) consider `null` values as valid.
This is generally useful as it allows combining constraints with `@NotNull`
only when required.
However, `@NotEmpty` and `@NotBlank` are exceptions to this rule - they
explicitly fail on `null` values.
This creates difficulty when validating nullable fields. For example, for
an optional string field that should be non-blank when present, there's no
clean, declarative way to express this constraint. The current workaround
requires creating custom constraints, which adds boilerplate for what seems
like a common use case.
Therefore, I'd like to propose introducing a new annotation, for example:
- `@NotBlankOrNull`, or
- `@NotBlankIfPresent`
This annotation would validate that a string is not blank only when it's
present (non-null), treating `null` as valid. This would align with other
constraints and provide a consistent way to validate optional, non-blank
strings.
Thank you for your time and consideration.
For reference, I have also opened an issue
<https://github.com/jakartaee/validation/issues/316> in the
jakarta-validation repository to discuss this, but haven't received
feedback there yet.
Best regards,
Ivan Malutin
1 month, 3 weeks
Re: Java 25 Released and New Leyden EA Builds
by Christian Beikov
Hey David,
Thank you for the updates. Everything looking good on our end:
Hibernate ORM: Version 7.1 tested against 25+36 / 26 (EA 15). No
problems to report.
Hibernate Validator: Version 9.1 tested against 25+36 / 26 (EA 15). No
problems to report.
Hibernate Search: Version 8.2 tested against 25+36 / 26 (EA 15). No
problems to report.
Hibernate Reactive: Version 4.2 tested against 25+36 / 26 (EA 15). No
problems to report.
Have a nice week,
Christian
Hibernate team
Am 23.09.2025 um 10:18 schrieb David Delabassee via hibernate-dev:
> Welcome to the latest OpenJDK Quality Outreach update.
>
> JDK 25[1] and JavaFX 25[2] were released as planned a few days ago. Additional Java 25 materials, including the "Road to 25" video series, are listed in the "Topics of Interest" section at the end of this update. If you missed it, you can also rewatch the Java 25 launch stream[3].
>
> Thank you to all the projects that contributed to this release by testing early access builds, providing feedback, or identifying issues. Your participation helps shape the Java platform!
>
> Let’s now turn our attention to JDK 26[4], which is expected to enter the Rampdown Phase in just over two months. As of today, three JEPs have already been targeted for inclusion in JDK 26. If you use JavaFX, please pay attention to the time-sensitive heads-up below.
>
> [1] https://blogs.oracle.com/java/post/the-arrival-of-java-25
> [2] https://inside.java/2025/09/23/javafx-25/
> [3] https://inside.java/2025/09/17/java25-launch-stream/
> [4] https://openjdk.org/projects/jdk/26/
>
>
> # Heads-up - JavaFX 26: Temporary switch to macOS Metal Rendering Pipeline
>
> On macOS, the default JavaFX rendering pipeline has been temporarily switched to Metal since JavaFX 26 early access build 5. This change will remain in place until October 8, 2025. The goal is to enable wider testing of the Metal rendering pipeline.
>
> If you need to revert to the previous macOS ES2 pipeline, you can do so by adding the `-Dprism.order=es2` flag to your Java command.
>
> The latest JavaFX 26 EA builds are now available for download[5] and testing. You can share your feedback on the openjfx-dev[6] list (registration required), through JBS[7] or bugreport.java.com[8].
>
> [5] https://jdk.java.net/javafx26/
> [6] https://mail.openjdk.org/mailman/listinfo/openjfx-dev
> [7] https://bugs.openjdk.org/
> [8] https://bugreport.java.com
>
>
> # Heads-up - New Leyden Early-Access Builds
>
> The purpose of Leyden early eccess builds is to prototype improvements in startup time, time to peak performance, and footprint of Java programs, with the hope that some of these enhancements can eventually be incorporated into future JDK releases. The Java community is invited to test these prototypes and provide feedback to the Project Leyden team.
>
> The latest Leyden "premain" prototype[9] introduces several experimental Ahead-of-Time (AOT) optimizations not yet part of the JDK mainline. These include AOT code compilation for frequently used methods, AOT generation of dynamic proxies and reflection data to improve start-up time, and a cache for failed class lookups to speed up repeated attempts. All these experimental features are, in the Leyden EA2 builds, enabled by default when creating an AOT cache and can be disabled via specific flags.
>
> More details on how to use these features can be found in the EA2 Release Notes[10]. Feedback should be sent to the leyden-dev[11] mailing list (registration required).
>
> [9] https://jdk.java.net/leyden/
> [10] https://github.com/openjdk/leyden/blob/leyden-ea2-release-notes/README.md
> [11] https://mail.openjdk.org/mailman/listinfo/leyden-dev
>
>
> # JDK 26 Early-Access Builds
>
> The JDK 26 early access builds 16 are available[12], and are provided under the GNU General Public License v2, with the Classpath Exception. You can review the Release Notes here[13].
>
> ## JEPs targeted to JDK 26, so far:
> - JEP 504: Remove the Applet API
> - JEP 517: HTTP/3 for the HTTP Client API
> - JEP 522: G1 GC: Improve Throughput by Reducing Synchronization
>
> ## Changes in recent JDK 26 EA builds that may be of interest:
> - JDK-8244336: Restrict algorithms at JCE layer
> - JDK-8366911: (fs) Remove support for normalizing file names to Unicode normalized form D (macOS)
> - JDK-8367112: HttpClient does not support Named Groups set on SSLParameters
> - JDK-8367031: [backout] Change java.time month/day field types to 'byte'
> - JDK-8366434: THP not working properly with G1 after JDK-8345655
> - JDK-8365086: CookieStore.getURIs() and get(URI) should return an immutable List
> - JDK-8364993: JFR: Disable jdk.ModuleExport in default.jfc
> - JDK-8364556: JFR: Disable SymbolTableStatistics and StringTableStatistics in default.jfc
> - JDK-8359443: Make jcmd command available in the headless JDK RPM
> - JDK-8362304: Fix JDWP spec w.r.t. OPAQUE_FRAME and INVALID_SLOT errors
> - JDK-8277585: Remove the terminally deprecated finalize() method from javax.imageio.stream APIs
> - JDK-8362448: Make use of the Double.toString(double) algorithm in java.text.DecimalFormat
> - JDK-8309400: JDI spec needs to clarify when OpaqueFrameException and NativeMethodException are thrown
> - JDK-8363972: Lenient parsing of minus sign pattern in DecimalFormat/CompactNumberFormat
> - JDK-8329829: HttpClient: Add a BodyPublishers.ofFileChannel method
> - JDK-8364227: MBeanServer registerMBean throws NPE
> - JDK-8361614: Missing sub-int value validation in the Class-File API
> - JDK-8361635: Missing List length validation in the Class-File API
> - JDK-8364751: ConstantBootstraps.explicitCast contradictory specification for null-to-primitive
> - JDK-8361613: System.console() should only be available for interactive terminal
> - JDK-8365676: javac incorrectly allows calling interface static method via type variable
>
> Note: A more exhaustive list of changes can be found here[14].
>
> [12] https://jdk.java.net/26/
> [13] https://jdk.java.net/26/release-notes
> [14] https://github.com/openjdk/jdk/compare/jdk-26+10...jdk-26+16
>
>
> # Topics of Interest
>
> - Java 25 Launch Stream
> https://inside.java/2025/09/17/java25-launch-stream/
>
> - The Arrival of Java 25
> https://blogs.oracle.com/java/post/the-arrival-of-java-25
>
> - JDK 25: G1/Parallel/Serial GC changes
> https://tschatzl.github.io/2025/08/12/jdk25-g1-serial-parallel-gc-changes...
>
> - JavaFX 25 Highlights
> https://inside.java/2025/09/23/javafx-25/
>
> - Road To 25: All API Additions From Java 21 to 25
> https://inside.java/2025/09/09/roadto25-api/
>
> - Road To 25: How to Handle Security Changes in Java 25
> https://inside.java/2025/09/07/roadto25-security/
>
> - Road To 25: Java 21 ⮕ 25 - Performance and Runtime Enhancements
> https://inside.java/2025/09/05/roadto25-performance/
>
> - Road To 25: All New Java Language Features Since Java 21
> https://inside.java/2025/08/31/roadto25-java-language/
>
> - Road To 25: Ahead-of-Time Computation
> https://inside.java/2025/08/28/roadto25-aot/
>
> - Road To 25: How to Upgrade to Java 25
> https://inside.java/2025/08/24/roadto25-upgrade/
>
> - JVMLS: Growing the Java Language
> https://inside.java/2025/08/21/jvmls-growing-java-language/
>
> - JVMLS: Auto-Vectorization in HotSpot
> https://inside.java/2025/08/16/jvmls-hotspot-auto-vectorization/
>
> - JVMLS: Paths to Support Additional Numeric Types on the Java Platform
> https://inside.java/2025/09/21/jvmls-java-additional-numeric-types/
>
> - Java Architects Answer Your Questions
> https://inside.java/2025/08/14/newscast-97/
>
> - GC-Agnostic Load Barriers for Ahead-of-Time Compilation
> https://inside.java/2025/08/27/thesis-gc-agnostic-load-barriers/
>
> ~
>
>
> This concludes the update. Please don’t hesitate to reach out if you encounter any issues while testing your projects with the latest JDK 26 early access builds.
>
> P.S.: If you no longer wish to receive these Quality Outreach updates, please let me know.
>
> --David
> _______________________________________________
> hibernate-dev mailing list -- hibernate-dev(a)lists.jboss.org
> To unsubscribe send an email to hibernate-dev-leave(a)lists.jboss.org
> Privacy Statement: https://www.redhat.com/en/about/privacy-policy
> List Archives: https://lists.jboss.org/archives/list/hibernate-dev@lists.jboss.org/messa...
1 month, 3 weeks
Hibernate organization membership on GitHub
by Yoann Rodiere
Hello,
As part of the move to Commonhaus, I'm currently going through our GitHub
setup, and I'm noticing we have a lot of users with extensive (and I mean
*extensive*, sometimes admin or even owner) access to our
organization/repositories, but who are no longer regular contributors.
Additionally, we also have organization members on GitHub who are not
technically Hibernate members: they have never actually contributed to
Hibernate, but are there for technical reasons, for example because they're
coworkers who helped out with some infrastructure issue.
While it's fine in principle, because we trust these people, it's very,
very far from security best practices. Account hacking happens, email
addresses get stolen, and the people using these GitHub accounts might one
day be an attacker instead of the person we trust.
According to Commonhaus' automated report, we're currently at 32 people
having admin rights on one Hibernate repository or another. Which I think
we can all agree is much more than necessary.
For that reason, I'd like to propose that:
1. *We create an "Alumni" team in our GitHub organization*, moving to that
team anyone who is actually a member, but hasn't contributed for... let's
say 2 years? Of course this isn't a permanent thing, and we can simply move
alumni back to the relevant team if they become active again.
2. *We move non-members out of our GitHub organization*, or to "external
collaborators" (that's a GitHub feature) if still necessary.
3. *We schedule yearly audits of our GitHub configuration* to review access
rights again in the future, and move people to the Alumni team as necessary.
Note moving people in and out of teams will get them notified, so I would
send another email directly to impacted people before/during the move, to
avoid this being seen as personal/insulting. It's really not.
*Thoughts, opinions, +1s?*
Yoann Rodière
Hibernate team
2 months, 1 week
