[hibernate-dev] JDK 27 Rampdown Phase Closing | Default G1 in All Environments

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