Helidon 27 is out. Helidon now numbers its releases after the JDK they require: releases will align with JDK releases, and the minimum Java requirement will bump to match the corresponding JDK release. Helidon 27 needs JDK 27. The previous release line was 4.x.
Helidon is Oracle's open source set of Java libraries for building microservices, Apache 2.0 licensed and first released in 2018.
It has historically shipped in two flavors: Helidon SE is a lean, library-style API where you wire things together yourself. Helidon MP implements Eclipse MicroProfile for developers who want the annotation-driven, Jakarta EE-style model.
Helidon 4 rebuilt the web server, called Níma, from the ground up to use Java 21 virtual threads, which let the SE APIs change from asynchronous to blocking without giving up throughput.
The change in 27 is the release model. Helidon has adopted the tip-and-tail model OpenJDK describes for library maintainers: a fast-moving tip that tracks the newest JDK and gets new APIs first, and a long-lived tail for teams that need a stable baseline. Helidon 27 is the tip, and Helidon 4.5 remains the LTS tail. Non-LTS tips are supported for six months, until the next tip, and Helidon 29 will be the next LTS release. Oracle has also placed Helidon in its new Java Verified Portfolio, a curated set of Oracle-validated Java tools, frameworks, and libraries with commercial support.
On features, Helidon Declarative, introduced in 4.3.0 as an inversion-of-control programming model for Helidon SE, now covers gRPC, Messaging, GraphQL, and OpenAPI. The APIs remain in preview, with finalization planned for Helidon 29 LTS. The release also introduces two major modules, Helidon Messaging and Helidon Data JDBC.
MicroProfile users should note that support has moved from the core repository into its own project, is not part of the Helidon 27 release, and will release independently. For MP shops, the practical answer today is 4.5.
The model asks something specific of its users: upgrade the JDK as routinely as upgrading a dependency. Teams that already work that way get new APIs on a six-month cadence. Teams that don't still have a supported place to stand. The version number now makes that choice clear.