Helidon – Java-based Cloud-native application development

In my last post, I wrote about Cloud-native app development in the Oracle Cloud (respectively Oracle Cloud Infrastructure, OCI). From that, we’ve now a rough idea about Cloud-native development, the principles behind it and what OCI offers to support Cloud-native applications. In this post – as promised in the last post -, I’ll give a brief introduction to Helidon, an open source framework that is mainly driven by Oracle.

Helidon – One framework, two implementation-styles

Helidon is basically a set of libraries for implementing Java-based Microservices resp. Cloud-native apps. So far, so good, but what’s the differentiating factor, since there are – as the figure below shows – a lot of those frameworks around these days?

Screen Shot 2020-04-05 at 20.38.42.png

Between those frameworks, we can distinguish Full-Stack, MicroProfile Based and Microframeworks.

The Full-Stack frameworks provide everything what is needed to implement a Microservice starting with accessing persistence services, implementing  business logic, exposing a respective REST service until providing a respective UI. Spring Boot is the most popular framework in this category, coming with a huge ecosystem for implementing various use cases.

The next category of frameworks are the MicroProfile ones. MicroProfile is a community-driven specification for the development of Java-based Microservices. It is hosted by the Eclipse Foundation and comprises a collection of individual specifications, partly borrowed from the classic Java EE or Jakarta EE space. Huge advantage of the  MicroProfile spec: it has no reference implementation – it’s just specs and interfaces. This makes the specification process lightweight and enables short release cycles. Scope and ecosystem are less pronounced in MicroProfile frameworks than in Full-Stack frameworks, which may impose limitations for certain use cases. On the other hand it makes those frameworks more intuitive and easy for newcomers to get started.

Last, but not least there are the so called Microframeworks. They’re often characterized by a reactive, non-blocking architecture and are optimized for fast startup as well as processing times. So they’re also well suited to be used in Serverless resp. Function as a Service (FaaS) scenarios. Frameworks of this category (or at least the core of the respective frameworks) usually dispense with any form of implicit “framework magic” like dependency injection. However, developers then take responsibility for certain processes themselves, such as the correct initialization of class and object networks or claiming and releasing of certain resources. Depending on the application scenario, this increases the amount of boilerplate code and the testing effort. On the other hand, these frameworks are extremely lightweight and flexible due to few external dependencies.

With these categorizations in mind and as it can also be seen from the figure above, Helidon comes in two flavours: A MicroProfile Based (Helidon MP) and Microframework (Helidon SE) one. This also answers the question about the differentiating factor of the framework.

Helidon framework architecture

To support the two implementation flavours, Helidon needs a respective framework architecture that is depicted in the figure below.

Screen Shot 2020-04-12 at 14.25.12

Basis for both framework variants is Netty, an asynchronous, event-driven framework.

Helidon SE is the lightweight, reactive variant of the framework and consists of an reactive web server and features with respect to flexible configurations as well as security. Helidon SE supports a functional programming model. The web server is characterised by a simple, functional routing model and provides support for OpenTracing, Metrics and Healthchecks. So this variant of the framework is a perfect fit for implementing reactive REST-based services.

Helidon MP is a MicroProfile implementation, currently supports MicroProfile version 3.2 and is built upon the basic components of Helidon SE. This variant of the framework supports the Java EE specifications for CDI, JAX-RS and JSON-B as well as JSON-P. In addition, Helidon MP is extensible using CDI-Extensions. Currently, such extension are available for JPA, JTA and specific extensions for accessing OCI-Resources like storage. So, this variant of the framework can be used for more advanced use cases.

With respect to flexibility, the framework variants provides both REST and gRPC-style service exposure, where gRPC is an experimental feature in the current version of the framework.

From a runtime perspective, Heldion runs on top of JDK 8+. In addition, Helidon SE applications provide support for GraalVM and can be compiled to GraalVM Native Images. The latter one is very interesting, especially to lower startup times and decrease the resulting Docker image’s size.


Helidon is flying! The current version is 1.4.4, a minor bugfix release comes nearly every month and in parallel the team is working on the next major release 2.0.0, which will drop JDK 8 support and will completely move to JDK 11 APIs. Furthermore, the following features will be added to the framework:

  • Reactive DB Client implementation (Helidon SE)
  • New reactive Web Client
  • Helidon CLI
  • MicroProfile Reactive Streams Operators (Helidon MP)
  • MicroProfile Reactive Messaging (Helidon MP)
  • WebSocket support
  • jlink image support
  • Preliminary GraalVM native-image support for Helidon MP

Some of the aforementioned features do have an experimental character and are suspect to change in case of further releases. Please checkout the release notes for Helidon 2.0.0-M1 and Helidon 2.0.0-M2. Within the release notes you can find some useful links to further blog posts, explaining some of the features in depth.


Helidon is a very interesting framework, when it comes to developing Cloud-native applications on top of the Java ecosystem.

From a developer’s point of view, Helidon’s approach is highly exciting: Developers can decide on a variant depending on the use case. The basic framework remains unchanged, only the programming model changes. This makes development more efficient and offers more flexibility in implementing business requirements.

In upcoming blog posts, I’ll go into more detail about developing services using Helidon and also how to run Cloud-native Helidon apps on top of Oracle Cloud infrastructure.