Helidon Takes Flight


Today is a great day. Today we introduce a new Java microservices frameworks and a new member of MicroProfile family. Please welcome Project Helidon — a new Java open source microservices framework from Oracle.

Helidon is a Greek word for “swallow”, a type of bird that according to Wikipedia has “a slender, streamlined body and long pointed wings, which allow great manoeuvrability and… very efficient flight”. Perfect for darting through the clouds.


The work on what would become the Helidon Project started some time ago. When we entered the cloud world, and microservices architecture started to become very popular for creating cloud services, we realized that the development experience also needed to change. It’s possible to build microservices using Java EE, but it’s better to have a framework designed from the ground up for building microservices. We wanted to create a lightweight set of libraries that didn’t require an application server and could be used in Java SE applications. These libraries could be used separately from each other, but when used together would provide everything a developer needs to create a microservice: configuration, security, and a web server.

There are already some efforts to build standard microservices frameworks from MicroProfile. MicroProfile is quite popular in the Java EE/Jakarta EE community and provide a development experience similar to Java EE. We like the idea and support the initiative. Helidon implements MicroProfile 1.1. We will continue working on implementing new versions of MicroProfile and intend to support relevant Jakarta EE standards in this area as they are defined.

Helidon is made by Oracle, so don’t be surprised that there will be some useful Oracle Cloud integrations. These are not included in the initial version, but will be added later. Helidon is already used by many internal Oracle projects and these integrations simplify our developers’ lives big time. We believe that will simplify your life as well if you use Oracle Cloud. If not, these integrations are optional.



Java Frameworks for writing microservices fall into a few categories. From smaller to larger:

  • Microframeworks
    Simple, fun, intentionally small feature set. Examples are Spark, Javalin, Micronaut, etc.
  • MicroProfile
    Friendly to Java EE developers but a bit heavier. Some of them are build on top of fully featured Java EE application servers. Examples are Thorntail (was Wildfly Swarm), OpenLiberty, Payara.
  • Full Stack
    Fuller features set such as Spring Boot.

Helidon comes in two flavours and covers two categories — Microframeworks and MicroProfile. It’s up to a developer to choose what to use in their applications.

  • Helidon SE — simple, functional, lightweight microframework developed in a modern reactive way. There is no injection “magic”. No special runtime required. JDK is used as runtime.
  • Helidon MP — Eclipse Microprofile implementation providing development experience familiar to Java EE/Jakarta EE developers.


Helidon’s high level architecture is shown on the picture below.


  • Helidon SE components are marked green. These are Config, Security and RxServer.
  • The Java EE/Jakarta EE components we use are marked grey. These are JSON-P, JAX-RS/Jersey and CDI. These components are required for MicroProfile implementation.
  • Helidon MP is a thin layer on top of Helidon SE components.
  • Oracle Cloud services components are marked red and used in both Helidon SE and Helidon MP.

Usage and Samples


The easiest way to start using Helidon is if you use a Maven project with Java 8 (or higher version) and configure the Helidon bom-pom:

Helidon SE

Helidon SE is the base to build lightweight reactive microservices.

A Hello world implementation:

This would start webserver on a random (free) port and expose endpoint /hello.


Dependency needed to start this example (version not required if you used bom-pom):

Adding metrics to SE

We have provided an implementation of MicroProfile Metrics interfaces also for Helidon SE (without support for injection, as that is not included in SE).

Updated source code with metrics:

This requires a new dependency:

New endpoints are available:

  • /metrics
    All metrics (base, vendor and application)
  • /metrics/application/helloCounter
    The metric created in our hello world application

Helidon MP

Helidon MP is Eclipse Microprofile implementation and a runtime for microservices.

A Hello world implementation that uses metrics to meter the invocations.

You must create a JAX-RS resource class to process your requests:

And then start the server with this resource:

You also need to create beans.xml file in the src/main/resources/META-INF directory to trigger CDI injection in this project:

This would start a webserver on the default port (7001) and expose endpoint /hello.

The following endpoints are available:


We have so many plans, I could write a separate article about them.

Our short term goal is to advertise Helidon in the Java community. We are planning to talk about Helidon at some conferences. We have four Helidon-related Oracle Code One 2018 talks planned. We have also submitted talks to EclipseCon Europe 2018 and will participate in the Jakarta EE/MicroProfile Community Day there. Some learning materials such as screen casts and YouTube videos are also on the way.

From the technical perspective, we are working on implementing the next MicroProfile versions very soon. We are also working on Oracle GraalVM support, which looks like a great feature for Helidon SE users.

We are working on some other cool stuff and features, but I can’t show all my cards now. Stay tuned, we will announce new features as soon as the are ready.

Useful Links

You may find it interesting

  • The original internal name of the project was J4C (Java for Cloud).
  • The Helidon team consists of two smaller teams in Prague (Czech Republic) and in the U.S.
  • Helidon is used in more than 10 projects within Oracle.
  • Some Helidon components are still in development and not open sourced yet.

Original article on my Medium blog.

Jakarta EE Challenges

Do you know that many famous people were born at the end of April? I’ll give you some samples. April 21 is the birthday of Queen Elizabeth II; Vladimir Lenin was born on April 22,  William Shakespeare on April 21, and Adolf Hitler on April 20. Maybe I shouldn’t include Hitler here, but he had a huge influence on 20th century history. Why do I mention this? Because on April 24, 2018, Jakarta EE was born. Using mathematical induction, we can predict that this newborn child will have a great influence on the Java world.

What’s the progress so far? There will be 39 projects under the umbrella EE4J project. 26 of them are already created. Others are in different states, but all them have been submitted for creation review. I made a table with a list of all of the projects, but it is quite big, so I included it in another article.

There are approximately 110 repositories to transfer, and about half of them have already been transferred.

Transferring projects may sound like an easy and straightforward process, but it’s not. It requires a lot of effort to transfer a project accurately. To help you understand, I’ll describe the steps to do it, and the challenges faced during this process. This should answer your “Why is it taking so long” questions that I often see in Twitter and on mailing lists.

  1. Internal license check

    We check all source files license headers to make sure they are correct. If not, we fix them. For old files it can be difficult to find an original file in a third party project.

  2. Internal third party analysis

    We run a third-party dependency analysis to identify which the dependencies should be replaced with their latest versions to fix major bugs and security issues. If these newer versions are not backward compatible with the older versions, then this requires some adoption work.

  3. Proposals creation

    In parallel with the steps above, we create project proposals in the Eclipse Foundation. The first challenge that we faced here is project granularity. We cannot (and don’t want) to create a project for every single repository. The Project Management Committee (PMC) decided to separate API and implementation projects and combine all satellite subprojects in the main project.
    Another challenge was how to name newly created projects. Names must not violate any required legal requirements and trademarks. It took quite a while to agree to use the “Eclipse Project for XXX” pattern for API projects (which typically used a name based on the Java trademark) and the “Eclipse XXX” pattern for implementation projects.
    The third challenge is to find contributors and leads. No one wants to contribute to old projects such as Enterprise Management.

  4. Initial Contribution

    When the proposal is created, approved, and has passed all required reviews, the project is created by the Eclipse Foundation. This allows us to start making an initial contribution and work with the Eclipse IP team to approve it. We submit one CQ (Contribution Questionnaire) for the initial contribution and one CQ for each project’s third party dependency. The Eclipse IP team often needs some clarification and may request changes. But if the license and third party work in steps 1 and 2 was done correctly, this step usually runs smoothly.

  5. Issues Transfer

    We created a special script to transfer issues. Our goal was to preserve issue numbers while doing the transfer to simplify the future work of updating web sites and issue links. The script took 8 hours just to transfer all of the Jersey issues.

  6. Build Environment

    We have to prepare a new build environment on Eclipse Foundation infrastructure. To help you understand the amount of work, the Compatibility Technology Kit (CTS) runs on a master machine with 50 slaves. CTS also requires a mail server and a JWSDP server, which are configured in a separate machine. To build GlassFish, we use 50 servers, and each server has 2 to 4 executors. So there are up to 200 executors in total. This configuration supports processing of up to 4 simultaneous pull requests. This is fine for normal development but not enough to process the intensive changes that usually happen at release time.
    For each EE4J project, we need to create Jenkins jobs to build the project, run unit tests, run TCK tests, and make nightly builds and Maven central releases. The Eclipse build infrastructure is different than what we use in Oracle, so all these jobs cannot be simply copied, they have to be reworked.

  7. Old projects shut down

    Java EE projects which have been transferred to the Eclipse Foundation have to be properly shut down. This requires updating project GitHub repositories and web sites with a message that this project has been transferred to the Eclipse Foundation. The message includes links to the new repository, issues tracker and project page. We are maintaining active Java EE communication channels, but we may shut them down in the future.

There were dozens of smaller challenges I didn’t put in the list. It was more difficult at the beginning. With experience, we know what to do and it goes faster. But we still have many challenges. One of them is transferring the CTS suite. It has never been open sourced, it’s full of third party dependencies, it’s in an SVN repository, and it’s huge. Maybe I should write another article about it. Another challenge is updating CI/CD jobs to use the new cloud-based build system recently introduced by the Eclipse Foundation.

I’d like to use this opportunity to ask the community to be more active and to contribute. Jakarta EE is a part of the open source foundation, and it belongs to the community. Your contributions are needed!

Subscribe to Jakarta EE community mailing list: jakarta.ee-community@eclipse.org
Contribute to EE4J projects: https://github.com/eclipse-ee4j
Jakarta EE on Twitter: @JakartaEE
Jakarta EE web site: https://jakarta.ee

Jakarta EE Technical Directions

Disclaimer: This is not an official EE4J PMC opinion.

This document is a product of my discussion with Oracle Prague development team consisting of engineers actively working on EclipseLink, Yasson. JSON-P, JPA, Metro, Jersey and other projects about technical directions each EE4J project should follow to make Jakarta EE successful:

  • Move stand-alone TCK from CTS to API projects

    Each API project should have TCK tests repository included in the project. I am putting it on top of the list because this effort is not trivial. All projects have to use the same standard mechanism for TCK. We don’t want to face a situation when different projects use different frameworks and it’s a challenge to run TCK tests for each of them. It will require some agreements and PMC statements about how new TCK tests are organized, what testing frameworks used, etc.

  • Embrace Java 9 modules

    Despite the fact that the first release of Jakarta EE will be JDK8 based, projects should start preparation for JDK9+ support. First step would be adding automatic-module-name in MANIFEST.MF. If it’s possible to provide a correct module-info.java, it should be done. If not, it can wait for the next project release.

  • Embrace Java SE

    If it’s possible, components should work natively in Java SE environment.

  • Switch to maven and use it properly

    Maven is a de facto standard build system for Java projects. There are some older EE4J projects which use Ant. It may be worth investing some time to their mavenization. Also, projects should use default maven directory structure and build process that doesn’t depend on Ant. Project build should produce standard Maven artifacts (sources.jar, binaries.jar, javadoc.jar) and be as simple as running ‘mvn clean install’ without providing complicated properties.  Also, it would be nice to agree on recommended version of Maven (and plugins) which should be used for next Jakarta EE release.

  • Deprecate old and unused technologies

    All components preserving backwards compatibility is growing in size and complexity. We should extract old and rarely used technologies to optional modules and leave it up to users if they want to use it. Good sample is SDO and JPA-RS in EclipseLink.

  • Prefer soft dependencies

    Think carefully before adding dependencies. Components depending on half of the world are heavy and not suitable for microservices development. Use modular approach allowing users to include only functionality needed in their application.

  • Integration with CDI and Config

    Dependency injection and configuration should be a base core included in all projects. It will provide a nice consistency between all Jakarta EE components if they are configured the same standard way.

  • Focus on testing

    I am not claiming that projects are not doing it. I am putting it here to remind developers that tests is very important part of every project. Specifications and APIs should be designed the way that applications implementing them can be easily tested.

If you have any questions, suggestions or not agree with statements above feel free to add comments or write me directly.

Thanks to Lukas Jungmann and Tomas Langer who helped me preparing this article.

Jakarta EE Projects Summary

Some people were complained that it’s difficult to find information about all Jakarta EE projects and their transfer status. I collected this information in the table below. For today it’s the most complete and accurate data. Links points to a project home page if the project is created and to a proposal if the project has not been created yet.

Project Description Status
Eclipse GlassFish GlassFish and satellite projects Created
Eclipse Grizzly Grizzly and satellite projects Created
Eclipse Jakarta EE Platform Jakarta EE Spec, schemas, etc. Pending
Eclipse Jakarta EE TCK CTS testing suite Pending
Eclipse Implementation of JAXB JAXB reference implementation + satellite projects Pending
Eclipse Jersey Jersey + WADL Created
Eclipse Metro JAX-WS reference implementation, SAAJ reference implementation, WSIT + satellite projects Pending
Eclipse Mojarra JSF reference implementation Created
Eclipse OpenMQ JMS reference implementation Created
Eclipse ORB ORB related repositories Pending
Eclipse Ozark MVC API reference implementation Pending
Eclipse Project for Common Annotations Common Annotations for the Java Platform, starting from the specification defined by JSR-250. Created
Eclipse Project for Concurrency Utilities Concurrency Utilities for Java EE, starting from the specification defined by JSR-236. Created
Eclipse Project for EJB Enterprise JavaBeans, starting from the specification defined by JSR-345. Pending
Eclipse Project for Enterprise Security Java EE Security API, starting from the specification defined by JSR-375. Created
Eclipse Project for Expression Language Java Expression Language, starting from the specification defined by JSR-341. Created
Eclipse Project for Interceptors Interceptors API, starting from the specification defined by JSR-318. Pending
Eclipse Project for JACC Java Authorization Contract for Containers, starting from the specification defined by JSR-115 Created
Eclipse Project for JAF JavaBeans Activation Framework, starting from the specification defined by JSR-925. In Review
Eclipse Project for JASPIC Java Authentication Service Provider Interface for Containers, starting from the specification defined by JSR-196. Created
Eclipse Project for JavaMail JavaMail, starting from the specification defined by JSR-919. Created
Eclipse Project for JAX-RS Java API for RESTful Web Services (JAX-RS), starting from the specification defined by JSR-370. Created
Eclipse Project for JAX-WS
  • Java API for XML-Based Web Services (JAX-WS) 2.0 (starting from the specification defined by JSR-224)
  • Java APIs for XML Messaging (starting from the specification defined by JSR-67)
  • Web Services Metadata for the Java Platform (starting from the specification defined by JSR-181)
In Review
Eclipse Project for JAXB Java Architecture for XML Binding (JAXB), starting from the specification defined by JSR-222. In Review
Eclipse Project for JCA Jakarta EE Connector Architecture, starting from the specification defined by JSR-322. Pending
Eclipse Project for JMS Java Message Service (JMS) API, starting from the specification defined by JSR-343. Created
Eclipse Project for JPA Java Persistence starting from the specification defined by JSR-338. Pending
Eclipse Project for JSON Processing Java API for JSON Processing, starting from the specification defined by JSR-374 + reference implementation. Created
Eclipse Project for JSON-B Java API for JSON Binding, starting from the specification defined by JSR-367. Created
Eclipse Project for JSP JavaServer Pages, starting from the specification defined by JSR-245. Created
Eclipse Project for JSTL JavaServer Pages Standard Tag Library, starting from the specification defined by JSR-52. Created
Eclipse Project for JTA Java Transaction API, starting from the specification defined by JSR-907. Created
Eclipse Project for Servlet Java Servlet API starting from the specification defined by JSR-369. Created
Eclipse Project for Stable EE4J APIs Legacy APIs. Currently contains

  • Enterprise Management API
  • Enterprise Deployment API
Eclipse Project for WebSocket Java API for WebSocket, starting from the specification defined by JSR-356. Created
Eclipse Soteria Enterprise Security API reference implementation Created
Eclipse Tyrus WebSocket API reference implementation Created
Eclipse Yasson JSON-B reference implementation Created
EclipseLink JPA reference implementation Created

I’ll try to keep this table updated when projects status is changed.

EclipseLink repository is moved to GitHub

As part of a process of transferring Java EE 8 to the Eclipse Foundation, EclipseLink source code repository was moved from Eclipse git to eclipse-ee4j organization on GitHub. It aligns EclipseLink with other EE4J projects and makes it more open to the community.

If you are a committer don’t forget to update your local copy!

New Location Old Location
Repository EE4J GitHub Eclipse git + Mirror
Issues Tracker EE4J GitHub + Eclipse BugZilla Eclipse BugZilla

From now on GitHub repository becomes a main working repository. All pull request and code reviews must be done there. Old repository on Eclipse git is switched to read only mode and will be eventually deleted as well as it’s mirror on GitHub.

I am also recommending using GitHib issues tracker for bugs submission the same way as other EE4J projects are doing. The old issues tracker is still active though.

Other project repositories (examples, etc.) will be also moved to EE4J GitHub in the nearest future.

JSON-P Sources are Transferred to Eclipse Foundation

Screen Shot 2018-01-11 at 21.43.24

Today is a big date. I just pushed JSON Processing sources to Eclipse EE4J GitHub repository.

See it live here: https://github.com/eclipse-ee4j/jsonp

It’s first sources which are actually transferred from Oracle to Eclipse. First two projects (Yasson and EclipseLink) were already in Eclipse Foundation, but under different root project.

More project coming soon! The firsts make history. And the first one was JSON-P!