Re: JDK 27 Rampdown Phase Closing | Default G1 in All Environments
by Christian Beikov
Hey David,
Thank you for the updates. Everything looking good on our end:
Hibernate ORM: Version 7.4 and 8.0 tested against 26.0.2+10 / 27-ea+34 /
28-ea+11. No problems to report.
Hibernate Validator: Version 9.1 tested against 26.0.2+10 / 27-ea+34 /
28-ea+11. No problems to report.
Hibernate Search: Version 8.4 tested against 26.0.2+10 / 27-ea+34 /
28-ea+11. No problems to report.
Hibernate Reactive: Version 4.4 tested against 26.0.2+10 / 27-ea+34 /
28-ea+11. No problems to report.
Have a nice week,
Christian
Hibernate team
Am 28.07.2026 um 11:42 schrieb David Delabassee via hibernate-dev:
> Welcome to the OpenJDK Quality Outreach summer update!
>
>
> Everything is on track for the general availability of Java 27 on 15 September, as JDK 27 is now in Rampdown Phase 2, meaning that only low-risk enhancements may still be considered. The first release candidate builds of JDK 27 are expected in just over a week, once RDP2 concludes. This also means that the window for testing your projects with JDK 27 has almost closed. If you haven’t done so, now is a good time to start testing your projects using the JDK 28 early-access builds.
>
> Also of note, G1 is becoming the default garbage collector across all environments in JDK 27. Make sure to check the Heads-Up below for more details.
>
> I’ll conclude by highlighting two non-technical resources that are nevertheless highly recommended: the Java documentary [1] and an episode of the Inside Java podcast [2] discussing JEPs and how critical they are to the evolution of the platform.
>
> [1] https://inside.java/2026/07/18/the-java-documentary/
> [2] https://inside.java/2026/06/25/podcast-060/
>
>
> # Heads-up - JDK 27: Default G1 in All Environments
>
> In situations where no garbage collector is specified on the command line, the HotSpot JVM used to select either G1 GC or Serial GC, depending on the environment. It preferred G1, but due to Serial's past throughput and footprint advantages in constrained environments, the JVM would select the latter if only a single CPU or less than 1792 MB of physical memory was detected.
>
> Recent work has made G1 competitive with Serial in those environments. Generally speaking, G1 will have similar native memory overhead, slightly lower throughput, and lower maximum latencies than Serial. To make it easier to reason about the JVM's behavior, starting with JDK 27, it picks G1 as default garbage collector in all environments.
>
> This change:
>
> - does not remove Serial GC from the JDK, which remains available in situations where its performance characteristics are preferable
> - does not interfere with applications that select a specific garbage collector on the command line
> - does not interfere with applications that run in environments with multiple CPUs and more than 1792 MB of memory
>
> That means an application is affected by this change only if it runs in a constrained environment and does not explicitly select a garbage collector. In such cases, we recommend benchmarking the application with different GCs to identify the one that best suits its needs. If that is not possible, the application can either use G1 as the new default or be configured to use Serial to ensure that its GC-related performance characteristics remain unchanged.
>
> For more information, please check JEP 523 [3].
>
> [3] https://openjdk.org/jeps/523
>
>
> # Heads-up - JDK 28: New jlink Keystore plugin
>
> A new `jlink` plugin has been introduced in JDK 28. It allows users to specify which CA certificates should be included in the `cacerts` keystore of a custom runtime image. This is useful for creating runtime images that contain only the CA certificates required by the applications that use those images. The command-line option accepts one or more `cacerts` keystore aliases, separated by commas.
>
> For more details, see [4].
>
> [4] https://bugs.openjdk.org/browse/JDK-8377102
>
>
> # JDK 27 Early-Access Builds
>
> The JDK 27 early-access builds for Build 32 are now available [5], along with the corresponding release notes [6].
>
> [5] https://jdk.java.net/27/
> [6] https://jdk.java.net/27/release-notes
>
> ## JEPs integrated into JDK 27:
>
> - JEP 523: Make G1 the Default Garbage Collector in All Environments
> - JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3
> - JEP 531: Lazy Constants (3rd Preview)
> - JEP 532: Primitive Types in Patterns, instanceof, and switch (5th Preview)
> - JEP 533: Structured Concurrency (7th Preview)
> - JEP 534: Compact Object Headers by Default
> - JEP 536: JFR In-Process Data Redaction
> - JEP 537: Vector API (12th Incubator)
> - JEP 538: PEM Encodings of Cryptographic Objects (3rd Preview)
>
> ## Changes in recent JDK 27 builds that may be of interest:
>
> - JDK-8381812: The synthetic $deserializeLambda$ is notably bigger [Reported by Eclipse Collections]
> - JDK-8382582: Remove the experimental JVMCI feature
> - JDK-8373426: Remove ffdhe6144 and ffdhe8192 from default list of TLS named groups
> - JDK-8385957: JFR: Sensitive command-line arguments still in environment v…
> - JDK-8381796: Enhance Certificate parsing
> - JDK-8368041: Enhance TLS certificate handling
> - JDK-8377833: Enhance Jar file processing
> - JDK-8380672: Improve certification checking
> - JDK-8360700: Implement JEP 534: Compact Object Headers by Default
> - JDK-8296183: jndiprovider.properties contains properties pointing to non-existing classes
> - JDK-8378464: PixelInterleavedSampleModel constructors and methods do not specify behavior …
> - JDK-8374348: Implement -XX:AOTMode=required as alias for -XX:AOTMode=on
> - JDK-8382031: Update IANA Language Subtag Registry to Version 2026-05-05
> - JDK-8357439: Add bash autocompletion for jcmd
> - JDK-8329548: Change KeyUpdate messages from TLS 1.3
> - JDK-8386466: DESedeKeySpec.isParityAdjusted spec permits 8-byte key but RI throws InvalidKeyException
>
> Note: A more exhaustive list of changes can be found here [7].
>
> [7] https://github.com/openjdk/jdk/compare/jdk-27+22...jdk-27+32
>
>
> # JDK 28 Early-Access Builds
>
> The JDK 28 early-access builds 8 are now available [8] for testing. You can review the Release Notes here [9].
>
> ## Changes in recent JDK 28 builds that may be of interest:
>
> - JDK-8385957: JFR: Sensitive command-line arguments still in environment v…
> - JDK-8384557: Allow configuration of the JVM's temporary directory on Linux
> - JDK-8301626: Capture Named Group information in TLSHandshakeEvent
> - JDK-8374058: Enhance JPEG handling
> - JDK-8387123: Remove LuxTrust Global Root CA
> - JDK-8386200: ListFormat incorrectly escapes single quotes
> - JDK-8385834: Tighten ListFormat.getInstance(String[]) behavior for invalid placeholders
> - JDK-6356745: (coll) Add PriorityQueue(Collection, Comparator)
> - JDK-8385304: X25519 should utilize aarch64 intrinsics
> - JDK-8380549: HttpCookie.expiryDate2DeltaSeconds returns 0 on parse failure, causing …
> - JDK-8376748: Emit runtime warnings for JCE algorithms that will be disabled
> - JDK-8386322: Float16Vector.toString should render lane values using Float16.toString
> - JDK-8387377: Compilation is very slow when --module-path contains many Automatic Modules …
>
> Note: A more exhaustive list of changes can be found here [10].
>
> [8] https://jdk.java.net/28/
> [9] https://jdk.java.net/28/release-notes
> [10] https://github.com/openjdk/jdk/compare/jdk-28+0...jdk-28+7
>
>
> # JavaFX 27 Early-Access Builds
>
> The latest early-access builds of JavaFX 27 are available [11], along with the corresponding JavaFX 27 Javadocs [12]. These EA builds enable JavaFX developers to build and test their applications with JavaFX 27 on JDK 27. Although they are designed to work with JDK 27-ea, they are also known to work with JDK 25 and later releases.
>
> [11] https://jdk.java.net/javafx27/
> [12] https://download.java.net/java/early_access/javafx27/docs/api/overview-su...
>
>
> # Topics of Interest
>
> - Java - The Documentary
> https://inside.java/2026/07/18/the-java-documentary/
>
> - “How JEPs Drive Java's Evolution” - Inside Java Podcast
> https://inside.java/2026/06/25/podcast-060/
>
> - “JDK 27 + Valhalla, Now!” - Inside Java Podcast
> https://inside.java/2026/07/19/podcast-062/
>
> - “Scripting JS and Python with Project Detroit” - Inside Java Podcast
> https://inside.java/2026/07/09/podcast-061/
>
> - Identifying JDK Value Class Candidate
> https://mail.openjdk.org/archives/list/core-libs-dev@openjdk.org/thread/Y...
>
> - SIMD Vectors in the HotSpot JVM - Auto Vectorization and the Vector API
> https://inside.java/2026/07/02/simd-vectors-hotspot-jvm/
>
> - ZGC: A Decade of Redefining Java Performance
> https://inside.java/2026/06/30/zgc-performance-decade/
>
> - Better Tools for Immutable Data
> https://inside.java/2026/06/21/better-tools-immutable-data/
>
> - Performance Improvements in JDK 26
> https://inside.java/2026/06/09/jdk-26-performance-improvements/
>
> - Java Next Language Features
> https://inside.java/2026/06/07/java-next-language-features/
>
> - “Java *is* Memory Efficient” - Inside Java Podcast
> https://inside.java/2026/05/28/podcast-059/
>
> ~
>
>
> As always, if you encounter any issues while running your project on JDK early-access builds, please feel free to reach out.
>
> P.S. If you would prefer not to receive future OpenJDK Quality Outreach updates, just 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
- 1
- 0
Retiring hibernate-users@lists.jboss.org
by Yoann Rodiere
Hey,
The mailing list hibernate-users(a)lists.jboss.org was originally intended
for discussion among Hibernate users. This is why it was not strictly
moderated, allowing anyone to post there.
I've rarely looked there, but upon checking recently, I realized it's
chock-full of spam. See
https://lists.jboss.org/archives/list/hibernate-users@lists.jboss.org/202...
for example.
This obviously makes the list pointless for users and creates legal
problems.
Someone apparently changed this list's settings some time ago, enforcing
moderation on all messages. But that only resulted in spam going to
moderators.
So I changed that list's settings again to reject all future messages,
making the list effectively read-only.
I don't think this will impact anyone considering the list was already
unusable and we have alternative ways for users to connect (forums, Zulip).
Those alternatives are documented at https://hibernate.org/community/ ,
which incidentally didn't even mention hibernate-users(a)lists.jboss.org.
Please let me know if you see a better solution.
Yoann Rodière
Hibernate team
1 month, 1 week
- 1
- 0
- ← Newer
- 1
- Older →