Hibernate ORM 8.0 Beta 1: Jakarta Persistence 4.0 and Graph-Based Flush
The first beta of Hibernate ORM 8.0 landed in the week of June 15, 2026, implementing the Jakarta Persistence 4.0-M5 specification and introducing two headline features that matter for teams running complex persistence layers.
The first is graph-based flush coordination. In previous Hibernate versions, the flush algorithm used a topological sort over entity dependencies, which could produce ordering surprises in bidirectional associations or when batch sizes and cascades interacted. The 8.0 beta replaces this with an explicit dependency graph that plans insert, update, delete, and collection operations before executing them, giving the persistence engine predictable ordering semantics regardless of how entities reference each other. Teams debugging flush ordering issues in large data models will want to test this early.
The second feature is row-level security for discriminator-based multi-tenancy. Rather than relying on application-level WHERE clause injection, Hibernate ORM 8.0 leverages the native row-level security policies of PostgreSQL, Db2, SQL Server, and CockroachDB. The database enforces tenant isolation at the storage layer, so queries that forget to include a tenant filter simply cannot leak data — a meaningful security guarantee for SaaS applications that share schema across tenants. Support is limited to Enterprise+ database editions where row-level security policies are available.
Jakarta Persistence 4.0 itself brings several API additions that Hibernate 8.0 exposes: the new find() variants with FindOption for lock mode and timeout hints, TypedQueryReference for compile-time-safe query references, and the new Jakarta Query Language enhancements. Developers upgrading from Hibernate 6.x should plan for the Jakarta Persistence 3.x to 4.0 migration, which includes package renaming and some API removals that the beta release notes document in detail.
Read more — InfoQ Java News Roundup
Helidon 4.5.0: Hardened Secrets and API Stability Annotations
Helidon 4.5.0 shipped alongside the June 15 Java roundup with three meaningful changes for teams running Helidon in production.
Configuration security gets a direct upgrade through enhanced value encryption for shared secrets. The hardened implementation strengthens the cryptographic guarantees when Helidon encrypts sensitive configuration values at rest, targeting scenarios where config stores are accessible to operators or third-party services but should not expose database passwords or API keys in plaintext. The release notes link to migration guidance for existing encrypted values.
The API stability initiative reaches completion in 4.5.0. Every public API element is now annotated with one of four stability designations — @Internal, @Preview, @Incubating, or @Stable — giving consumers a clear contract about what will be maintained across upgrades. This mirrors the approach taken by Quarkus and Micronaut and makes it easier for library authors to reason about which Helidon APIs they can safely depend on without risking breakage in patch releases.
HTTP/2 reliability improves through stricter HPACK header compression validation: the 4.5.0 release rejects malformed integers in HPACK-encoded headers, closing a potential vector where a misbehaving client could trigger undefined parsing behaviour in the server. The fix aligns Helidon's HTTP/2 implementation more tightly with the RFC 9113 specification requirements. Teams running Helidon behind untrusted HTTP/2 clients should treat this as a recommended upgrade.
Read more — InfoQ Java News Roundup
Quarkus CVE-2026-50559: Emergency Patches for Path Bypass Vulnerability
The Quarkus team shipped emergency maintenance releases across five active release trains — 3.20, 3.27, 3.33, 3.36, and 3.37 — to address CVE-2026-50559, a vulnerability in how the framework resolves static resource paths under its security layer.
The root cause is insufficient decoding of percent-encoded characters in request URIs. An attacker can supply a URL containing encoded semicolons (%3B), encoded forward slashes (%2F), or encoded backslashes (%5C) that bypass the security interceptor's path matching while the underlying Vert.x layer normalises them before file lookup. The net effect is that protected static resources become accessible without authentication. The vulnerability extends the blast radius of an earlier related CVE and affects applications that serve protected static content through Quarkus's built-in static resource handling.
All affected versions have been patched; the fix normalises and decodes percent-encoded characters before security policy evaluation rather than after. Teams should upgrade to the patched maintenance release within their current release train. The emergency releases contain no other feature changes or dependency upgrades, so the upgrade risk is low. Applications that do not serve protected static content over HTTP, or that proxy all requests through a WAF or API gateway that normalises URLs, are less immediately exposed but should still upgrade at the next maintenance window.
For teams unable to upgrade immediately, the Quarkus team recommends configuring an explicit allowlist of legal request path characters at the Vert.x router level or at the load balancer, and blocking requests that contain percent-encoded path separators.
Read more — InfoQ Java News Roundup
