JDK 27 Formally Targets Project Valhalla: Value Classes Enter Preview
JDK 27's release schedule is now locked: Rampdown Phase One forks from the main line on June 4, 2026, with General Availability set for September 2026. The headline feature is JEP 401, which brings value classes to JDK 27 as a preview — representing a concrete milestone for Project Valhalla after years of design and incubation.
Value classes are declared with the value keyword and enable the JVM to flatten instances directly onto the heap or stack, eliminating object header overhead and pointer-chasing for small data types. This has significant implications for performance-sensitive code such as numeric computations, geometry libraries, and financial data processing, where boxing of primitives into heap-allocated wrappers currently imposes unnecessary overhead. The JVM can treat value class instances as if they were primitives when performing operations like array storage and field access.
Alongside Value Classes, JEP 527 (Post-Quantum Hybrid Key Exchange for TLS 1.3) has also been targeted for JDK 27. This JEP implements hybrid key exchange algorithms combining X25519 with ML-KEM-768, providing defense against future quantum computing attacks without abandoning proven classical algorithms. Security-sensitive applications dealing with long-lived encrypted data should begin tracking this feature as it moves toward standard status.
Other JDK 27 candidates in progress include lazy static final fields (JEP draft) and further preview rounds for primitive types in patterns (JEP 532) and structured concurrency. Developers wanting to track the evolving release can follow early-access builds at jdk.java.net/27.
Read more — JVM Weekly
OpenJDK Bans AI-Generated Code Contributions
The OpenJDK project has adopted a formal policy banning AI-generated code from being submitted as contributions. The policy cites two primary concerns: the significant additional burden placed on reviewers to manually audit AI-generated patches for correctness and subtle errors, and security risks stemming from the hallucinated or subtly incorrect logic that current AI coding assistants can introduce into low-level runtime and library code.
The ban covers code submitted in pull requests and patches to any OpenJDK repository. Private use of AI assistants for comprehension — such as using an LLM to understand an existing algorithm or to explore alternative approaches — remains explicitly permitted. The distinction the project draws is between AI as a research aid (acceptable) versus AI as a direct contributor to the authoritative codebase (not acceptable).
This policy contrasts with GraalVM's publicly stated responsibility-based approach, which places the burden on the contributor to ensure correctness regardless of how the code was generated. The OpenJDK stance reflects a conservative position consistent with its role as the foundation for millions of production deployments: the cost of a subtle JVM bug far outweighs the productivity gains from accepting AI-assisted patches without rigorous re-review.
For Java developers contributing to open source projects, this signals that even where AI tools are permitted, reviewers in foundational projects will demand extra rigor — and that upstream Java tooling itself will remain human-reviewed code for the foreseeable future.
Read more — JVM Weekly
Links & Sources
You May Also Enjoy
