If you are a back-end developer, or work with back-end developers, I strongly recommend watching this presentation: Helidon Nima - Loom based microservices framework
At Forgerock, we use Helidon SE and ME for some of our microservices, where SE is like the engine, and ME is the whole car, including the engine. Later this year (2023), Helidon version 4.0 should be released with Helidon Níma, where eventually Helidon ME will use Níma instead of SE.
Helidon SE
is based on Reactive Programming techniques (see also The Reactive Manifesto), in particular the Java Flow API introduced in Java 9.
Helidon Níma
is based on conventional imperative blocking code, but using Java Loom Virtual Threads. Our friends at Okta wrote a great description of Loom in What the Heck Is Project Loom for Java? But sometimes it’s best to hear it from the masterminds themselves, The Age of Virtual Threads by Ron Pressler And Alan Bateman.
Comparison
| Helidon SE | Helidon Níma |
|---|---|
| Based on less intuitive, Non-Blocking, Reactive Programming, typically Functional Programming style | Based on more intuitive, conventional Blocking Programming, may be Imperative or Functional style |
| Fast, efficient, low overhead, high throughput | Fast, efficient, low overhead, high throughput |
| Complex, harder to write, harder to read, harder to debug, harder to test | Simpler, easier to write, easier to read, can use conventional debugging practices, easier to test |
| Helidon ME has excellent throughput | Helidon ME has twice the throughput |
| Helidon 3.0 requires Java 17 | Helidon 4.0 requires Java 19, but the target should be Java 21 for its Long Term Support |
Looking Forward
-
Because both Helidon and Java are developed at Oracle, the Loom and Níma teams have been working together to test this new technology together.
-
While Níma may not be using Structured Concurrency yet, it almost certainly will by Java 21. In the meantime, we can use Structured Concurrency with Níma today.
- Structured Concurrency should be much preferred over Executors
- Also, Virtual Threads should never be used with Thread Pools, where Structured Concurrency uses Virtual Threads by default
-
Ultimately, Helidon Níma will deliver more performant microservices, that are easier to develop, debug, and test… basically an overall better Developer Experience, that improves ROI by decreasing TCO.
- While the Developer Experience is better, there are some old habits than should be unlearned
- e.g. Virtual Threads should never be used with Thread Pools
- For more details, see The Age of Virtual Threads by Ron Pressler And Alan Bateman
- While the Developer Experience is better, there are some old habits than should be unlearned
-
Helidon applications can use JLink for smaller runtime and faster startup, and can use GraalVM for the fastest startup.
- GraalVM Polyglot features enable building efficient, small, performant multi-language web applications
-
Friends don’t let friends use Spring
(did he really say that? 
). Actually, using GraalVM, even Spring applications can be smaller with faster startup.