Helidon 27: Java Microservices on Virtual Threads, and Who Should Adopt It

What Helidon Is and Which Java Teams It Fits

Helidon describes itself as a set of Java libraries for writing microservices. That phrasing matters more than it looks. There is no application server to install and no runtime binary to download. The README states plainly that there are no Helidon downloads and that you use the Maven releases under GroupID io.helidon. Your service is a Java SE program that pulls in the libraries it needs.

The project ships two programming models. Helidon SE is the programmatic, library-oriented side, where you assemble the server and routes in code. Helidon MP implements MicroProfile, the Jakarta EE-derived set of specifications for configuration, health checks, metrics, and REST endpoints driven by annotations. Teams coming from Jakarta EE or from older MicroProfile runtimes tend to recognize the MP style immediately. Teams that want to see exactly what the server does at startup tend to prefer SE.

The audience is narrower than a general Java web framework. Helidon 27 requires Java 27, and the README says so without hedging. If your organization is still on Java 17 or 21 for production services, the current Helidon line is not a drop-in choice, and version 4.5.5 remains the release to look at instead.

Níma, Virtual Threads, and the Thread-per-Request Model

The architectural claim in the README is specific: an application runs on the Helidon Níma WebServer, which the project says was written from the ground up to use Java 27 virtual threads. The stated benefit is that you get the throughput of a reactive server with the simplicity of thread-per-request programming.

That is a real trade-off being made, not a slogan. Reactive frameworks ask developers to write non-blocking code, chain callbacks or publishers, and reason about which thread a continuation resumes on. Virtual threads move that scheduling into the JDK: a request occupies a virtual thread, blocking calls park that thread cheaply, and the code reads sequentially. The cost is that the JVM must be new enough to have mature virtual thread support, which is why Helidon 27 pins itself to Java 27 rather than supporting a range of JDKs.

The repository layout reflects the split between the server and the surrounding libraries. Top-level directories include webserver, webclient, config, security, health, metrics, tracing, and grpc, alongside json, jsonrpc, and graphql. The reactive topic tag on the repository points at the Netty heritage of earlier Helidon lines, but the Níma server is the piece the README foregrounds for version 27. If you are evaluating throughput claims, the documentation is where to look, not this article.

Installing Helidon and Getting a First Service Running

Because there are no downloads, installation means adding Maven dependencies under GroupID io.helidon, or using the Helidon CLI to scaffold a project. The CLI is the faster path for a first look. On macOS, the README gives this sequence, which downloads the binary, marks it executable, and moves it onto the PATH:

curl -O https://helidon.io/cli/latest/darwin/helidon
chmod +x ./helidon
sudo mv ./helidon /usr/local/bin/

Linux uses the same three commands with a different URL, and Windows uses a PowerShell download to C:\Windows\system32\helidon.exe. The README points to HELIDON-CLI.md in the repository for detail beyond the install steps.

If you are building the framework itself rather than an application, you need JDK 27 and Maven, with the README recommending 3.8.0 or newer. A full build is one command from the repository root:

mvn install

Individual quality profiles run per component. From the component directory, mvn validate -Pcheckstyle runs the style check, mvn validate -Pcopyright runs the copyright check, and mvn verify -Pspotbugs runs Spotbugs. Documentation is built from the docs directory with mvn package -Pjavadoc. For application code, the README directs new users to the getting started guide at docs/get-started.md and to helidon.io, and it tells anyone moving from Helidon 4 to read docs/guides/upgrade/27.md for changes to dependencies, APIs, and application configuration.

The Java 27 Floor and Other Constraints to Weigh

The clearest limitation is the one the project states itself: Java 27 is required to use Helidon 27. That is a hard floor, not a recommendation. Any team whose deployment standard is an earlier LTS release has to either upgrade the whole toolchain or stay on the 4.x line, which is still receiving releases. The upgrade guide exists precisely because dependencies, APIs, and application configuration all change between the two lines, so the migration is not a version bump in a pom file.

A second constraint follows from the distribution model. With no downloadable runtime, you are responsible for packaging and running the service yourself. There is no vendor-supplied server image to fall back on, which is fine for container-based teams and less convenient for anyone expecting a managed runtime.

The documentation is also split. The README sends readers to helidon.io for getting started and to docs/README.md for version-specific documentation, while the FAQ lives on a GitHub wiki and support runs through Stack Overflow and a Slack channel. That is a normal open source arrangement, but it means the authoritative answer to a question may be in a wiki page rather than in the repository, and the README does not describe a rollback procedure or a long-term support policy for the 27 line.

Helidon SE and Helidon MP: Two Models, One Runtime

The distinction between Helidon SE and Helidon MP is the question most new users ask, and it is worth answering concretely. MP is the MicroProfile programming model: annotations, dependency injection, configuration through MicroProfile Config, and specification-driven endpoints. If your team has written MicroProfile services before, the code will look familiar, and the repository's microprofile topic tag confirms that this is a first-class part of the project rather than a compatibility shim.

SE is the opposite posture. You construct the server and register routes explicitly, and you choose which Helidon libraries to include rather than adopting a specification stack. The practical difference shows up in startup time, dependency footprint, and how much of the behavior is visible in your own code versus supplied by the container.

Neither model is deprecated, and both run on the same Níma server. The choice is about team experience and how much framework you want between your code and the request. A team that has never used MicroProfile will find SE easier to reason about; a team migrating an existing MP application will find that MP preserves far more of its structure.

How Helidon Differs from Spring Boot, Quarkus and Micronaut

The comparisons people search for are Helidon versus Spring Boot, Quarkus, and Micronaut, and the honest difference starts with the JDK. Helidon 27 requires Java 27. Spring Boot is built to run across a broad range of supported Java versions, and Quarkus and Micronaut likewise support multiple JDK baselines. If your constraint is a mixed fleet of Java versions, Helidon 27 is the least flexible of the four on that axis.

The second difference is the concurrency model. Helidon 27's answer to throughput is virtual threads on the Níma server, which keeps blocking-style code viable. Quarkus and Micronaut lean on build-time processing and, in Quarkus's case, a reactive core with an imperative layer on top. Spring Boot's reactive option is WebFlux, a separate stack from the servlet-based one. Helidon's pitch is that you get one model rather than two.

The third is ecosystem. Spring Boot has the largest body of third-party starters and integrations, and Quarkus and Micronaut both have extension catalogs. Helidon's own library set covers config, security, health, metrics, tracing, gRPC, GraphQL, and database clients, but if you depend on a specific third-party integration, check whether an io.helidon equivalent exists before committing.

Licence, Maintenance and Upgrade Cost

Helidon is available under Apache License 2.0, and the repository carries LICENSE.txt, NOTICE.txt, and THIRD_PARTY_LICENSES.txt at the top level. Apache-2.0 is permissive, permits commercial use, and includes a patent grant. The third-party licence file is the one to read if you redistribute the libraries, since transitive dependencies carry their own terms. This is a description of the licence text, not legal advice.

The repository is not archived, and the last push was on 2026-09-23. Recent releases are 27.0.0 from 2026-09-22, with 4.5.5 and 3.2.21 both from 2026-09-15. That pattern is worth noting: three lines are being released in parallel, so the 27 line is not the only one receiving attention. If you adopt 4.5.5 today, you are not on an abandoned branch.

Upgrade cost is where the version lines bite. The README explicitly directs Helidon 4 users to docs/guides/upgrade/27.md because dependencies, APIs, and application configuration change. Plan for that work as a project, not a maintenance task. The README does not describe a support window or deprecation policy for any line, so if long-term support commitments matter to your organization, that is a question for the project's own channels rather than something the repository answers.

Editorial conclusion

Adopt Helidon if you are starting a new Java microservice, your build already targets JDK 27, and you want thread-per-request code without a reactive programming model. Do not adopt it if you cannot move to Java 27, or if you need a Spring Boot or Quarkus ecosystem of extensions and integrations. Before committing, verify the io.helidon artifact versions you need exist in Maven Central, read the Helidon 27 upgrade guide at docs/guides/upgrade/27.md, and confirm which of the two programming models, Helidon SE or Helidon MP, matches your team's experience.

Frequently asked questions

Official sources

1. helidon-io/helidon on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases