Helidon brings MicroProfile 2.2+ support

We are pleased to announce the 1.2.0 release of Helidon. This release adds support for MicroProfile 2.2 and includes additional bug and performance fixes. Let’s take a closer look at what’s in the release.

MicroProfile

MicroProfile is now a de-facto standard for Java cloud-native APIs. One of the main goals of project Helidon is to deliver support for the latest MicroProfile APIs. The Helidon MicroProfile implementation is called Helidon MP and along with the reactive, non-blocking framework called Helidon SE it builds the core of Helidon.

We have been adding support for newer MicroProfile specifications one by one during the last few releases. The 1.2.0 release brings MicroProfile REST Client 1.2.1 and Open Tracing 1.3. With these pieces in place we now have full MicroProfile 2.2 support.

The full list of supported MicroProfile and Java EE APIs is listed on this image:

As you see, we added support for two more Java EE APIs: JPA (Persistence) and JTA (Transaction). It’s in early access at the moment. You should consider it as a preview. We are still working on it and the implementation and configuration is subject to change.

Here are some examples of using new APIs added in Helidon 1.2.0.

MicroProfile REST Client sample

Register a rest client interface (can be the same one that is implemented by the JAX-RS resource). Note that the URI can be overridden using configuration.

@RegisterRestClient(baseUri = "http://localhost:8081/greet")
public interface GreetResource {
    @GET
    @Produces(MediaType.APPLICATION_JSON)
    JsonObject getDefaultMessage();
    
    @Path("/{name}")
    @GET
    @Produces(MediaType.APPLICATION_JSON)
    JsonObject getMessage(@PathParam("name") String name);
}

Declare the rest client in a class using it (such as a JAX-RS resource in a different microservice):

@Inject
@RestClient
private GreetResource greetService;

And simply use the field to invoke the remote service (this example proxies the request to the remote service):

@GET
@Produces(MediaType.APPLICATION_JSON)
public JsonObject getDefaultMessage() {
    return greetService.getDefaultMessage();
}

Health Check 2.0 sample

Health Check 2.0 has two types of checks (in previous versions a single type existed):

  • Readiness — used by clients (such as Kubernetes readiness check) to check if the service has started and can be used
  • Liveness — used by clients (such as Kubernetes liveness checks) to check if the service is still up and running

Simply annotate an application scoped bean with the appropriate annotation (@Readiness or @Liveness) to create a health check:

import javax.enterprise.context.ApplicationScoped;
import javax.inject.Inject;
import org.eclipse.microprofile.health.HealthCheck;
import org.eclipse.microprofile.health.HealthCheckResponse;
import org.eclipse.microprofile.health.Liveness;

@Liveness
@ApplicationScoped
public class GreetHealthcheck implements HealthCheck {
    private GreetingProvider provider;
  
    @Inject
    public GreetHealthcheck(GreetingProvider provider) 
        this.provider = provider;
    }

    @Override
    public HealthCheckResponse call() {
        String message = provider.getMessage();
        return HealthCheckResponse.named("greeting")
            .state("Hello".equals(message))
            .withData("greeting", message)
            .build();
    }
}

Open Tracing Sample

MP Open Tracing adds a single annotation: @Traced, to add tracing to CDI beans.

Tracing of JAX-RS resources is automated (and can be disabled with the @Traced). Example of the bean used in the Health check example (the method getMessage is traced):

@ApplicationScoped
public class GreetingProvider {
    private final AtomicReference<String&gt; message = new AtomicReference<&gt;();
    
    /**
     * Create a new greeting provider, reading the message 
     * from configuration.
     *
     * @param message greeting to use
     */
    @Inject
    public GreetingProvider(
        @ConfigProperty(name = "app.greeting") String message) {
        this.message.set(message);
    }
    
    @Traced(operationName = "GreetingProvider.getMessage")
    String getMessage() {
        return message.get();
    }
    
    ...
}

Other Enhancements

In addition to MicroProfile 2.2, Helidon 1.2.0 contains a couple other enhancements:

  • HTTP Access Log support for Helidon MP and SE.
  • Early Access: Oracle Universal Connection Pool support: this lets you configure and inject the Oracle UCP JDBC driver as a DataSource in your Helidon MP application.

More to Come

With MicroProfile 2.2 support, Helidon has caught up with most of the other main MicroProfile implementations. We are now pushing Helidon towards MicroProfile 3.0, and we’ve already taken the first steps. That’s why we put a plus after 2.2 in the title. We already have support for Health Check 2.0 (and we’ll support it in a backwards compatible way). That leaves Metrics 2.0 and REST Client 1.3 and we are working hard to deliver it next month.

Stay tuned!

Thanks to Tomas Langer for helping with samples and to Joe Di Pol for great conversational style.

Thoughts about Jakarta EE future without ‘javax’

This week Mike Milinkovich announced that Oracle and the Eclipse Foundation agreed that the javax package cannot be evolved by Jakarta EE community and Java trademarks cannot be used in Jakarta EE specifications. How critical is it to Jakarta EE community? Can Jakarta EE survive without javax namespace? Here are my thoughts about it.

For sure, it would be much better to evolve existing APIs in javax packages without any restrictions. But we have what we have and I am not going to do complaining and blaming here. There were reasons to do it this way. On the other hand, finally, the uncertainties with Java trademarks are gone. It’s very important because Jakarta EE progress is not blocked anymore. Javax package restrictions draw a clear line separating Java EE and Jakarta EE, separating past and future. Javax becomes a legacy. All innovations will belong to jakarta namespace. Now it’s clear that javax packages cannot be modified and community needs to find a way how to evolve specifications. And there are some options how it can be done. We need to maximize compatibility with Jakarta EE 8 for future versions without stifling innovation. It’s what Jakarta EE Spec Committee agreed on.

In my opinion the best would be to make a big-bang javax->jakarta package rename to untie the community hands and allow modifications and APIs evolution. It will break the backwards compatibility which was always an important part of Java EE platform and we should not forget about it. There are thousands of Java EE applications and it won’t be wise to remove backwards compatibility requirements. A good option is to create a special backwards compatibility profile in Jakarta EE platform. This profile should contain a frozen Java EE 8 APIs and will allow to run Java EE 8 applications on future versions of Jakara EE Platform. This profile can be optional to allow new potencial Jakarta EE vendors concentrate only on innovations, but I am sure that all big players such Oracle and IBM will support it anyway.

This kind of solution is not new for the industry. For example, in 2006 Sony released PlayStation 3 system which used new architecture and was not compatible with the previous PlayStation 2 system on the hardware level. They solved it by adding PS2 chip to the first versions of PS3 consoles allowed to run PS2 games on it.

Another sample is a process of changing CPU in Apple Macintosh computers from PowerPC to Intel. They provided a simulator allowing running PowerPC application on new Intel based computers for some limited time until most of the applications migrated to the new platform.

How the backwards compatibility can be implemented technically? One of the obvious and straightforward solutions is supplying two implementations: one is supporting javax and and another supporting jakarta. Javax implementations are already exist as part of Java EE 8. Jakarta implementations can be created by forking javax implementations and make necessary modifications.

Another way is patching application binaries at runtime or build time. Runtime solution can be accomplished using JavaAgent and build time via tooling and build plugins.

To simplify migration to jakarta package on the source level, the community may think of creating IDE plugins replacing javax with jakarta the clever way with one click.

I am working in different Jakarta EE committees and see the intention of participants to remain committed to Jakarta EE work, finish Jakarta EE 8 and push it forward to provide a robust, compatible and innovative enterprise platform.

Helidon flies faster with GraalVM

GraalVM is an open source, high-performance, polyglot virtual machine developed by Oracle Labs. GraalVM offers multiple features, including the ability to compile Java code ahead-of-time into a native executable binary. The binary can run natively on the operating system, without a Java runtime

A native executable offers important benefits, like shorter startup time and lower memory footprint. In addition, when a native executable runs within a container, the size of the container image is reduced (when compared with the same Java application running in a traditional JVM), because the container image doesn’t include a Java runtime. An optimized container size is critical for deploying apps to the cloud.

We are pleased to announce that, starting with version 1.0.3, Helidon supports the GraalVM native-image capability. Now you can easily compile your Helidon application into a native executable with all the advantages described earlier. For example, the sample application described in this article has a startup time measured in tens of milliseconds and a MacOS executable size of only 21MB. Both of those numbers are higher when a traditional JVM is used.

On the other hand, everything is always a tradeoff. Long running applications on traditional JVMs are still demonstrating better performance than GraalVM native executables due to runtime optimization. The key word here is long-running; for short-running applications like serverless functions native executables have a performance advantage. So, you need to decide yourself between fast startup time and small size (and the additional step of building the native executable) versus better performance for long-running applications.

Compiling to native binaries introduces certain restrictions for your application. Because of native compilation, you must identify all the points in your code where reflection is used, which is not possible if CDI runtime injection is used. Helidon MP supports MicroProfile standards, which require CDI 2.0. Also, Helidon CDI cloud extensions are implemented as CDI plugins. We didn’t want to limit or complicate the user experience with Helidon MP; so GraalVM is supported in only Helidon SE. It is a perfect fit, because Helidon SE is designed to build small, reactive microservices. It doesn’t use dependency injection, annotations and other such magic . All the Helidon SE features and components (WebServer, Config, Security, Metrics, and Health Checks) are compatible with GraalVM native images.

Helidon supports two convenient GraalVM profiles:

  • The local profile is for users who have GraalVM installed locally and want to build a native executable for the same OS that they work on.
  • The Docker profile is for users who don’t have GraalVM installed locally or want to build native executable for Linux while using macOS locally.

Due to the possibility of backwards incompatible changes in GraalVM before the final release, the GraalVM support in Helidon is experimental. It’s been tested on GraalVM version RC13; it is not guaranteed to work on other GraalVM versions.

To get you started, Helidon has a quickstart sample, which you can use as a template for your Helidon-on-GraalVM application.

Generate the project using a Maven archetype:

mvn archetype:generate -DinteractiveMode=false \
    -DarchetypeGroupId=io.helidon.archetypes \
    -DarchetypeArtifactId=helidon-quickstart-se \
    -DarchetypeVersion=1.0.3 \
    -DgroupId=io.helidon.examples \
    -DartifactId=helidon-quickstart \
    -Dpackage=io.helidon.examples.quickstart

To build using the local profile you need to download GraalVM, extract it to some folder on your computer and define GRAALVM_HOME environment variable pointing to it.

If you use macOS, GRAALVM_HOME must point to Contents/Home directory inside the GraalVM root as it’s shown below.

export GRAALVM_HOME=~/graalvm-ce-1.0.0-rc13/Contents/Home

Build the project:

mvn package -Pnative-image

Run it:

./target/helidon-quickstart

If you want to use Docker profile, GraalVM installation is not required. Use the following command to build a docker image:

docker build -t helidon-native -f Dockerfile.native .

Run it as:

docker run --rm -p 8080:8080 helidon-native:latest

Helidon is a Java framework designed from scratch for writing microservices. It provides everything that you need to create small and efficient Java applications. It offers two programming models: reactive, and imperative supporting MicroProfile.

With GraalVM support, Helidon is one of the best solutions in the market for developing cloud-native microservices!

Do join our open-source community! We care about our users, and are ready to support you and answer your questions.

Update

We tested it with newly released GraalVM RC16 (both CE and EE versions) and it perfectly works.

Helidon 1.0 is Released

I am proud to announce that Helidon 1.0 is released. This version brings full MicroProfile 1.2 support in Helidon MP, support for Yasson and Jackson in Helidon SE, and contains bug fixes and performance improvements. We have finished the API changes that we’ve been working on over the last few months. From this point on we will have much greater API stability.

More details are in release notes.

Eclipse GlassFish 5.1 is released

I am very excited to bring you some great news. Today Eclipse GlassFish 5.1 has finally been released and available

on Maven Central:

or can be downloaded from Eclipse web site:

A huge milestone has been reached. Eclipse GlassFish 5.1 is a pure Eclipse release. All components formerly supplied by Oracle have been transferred to the Eclipse Foundation from Oracle Java EE repositories, have passed the Eclipse release review, and have been released to Maven Central with new licensing terms. Eclipse GlassFish 5.1 has passed all CTS/TCK tests (run on Oracle infrastructure) and has been certified as Java EE 8 compatible.

CTS tests results (copied from Oracle infra):

This release doesn’t contain any new features. The feature set is the same as in Oracle GlassFish 5.0.1. The main goal was to demonstrate that GlassFish and all other components transferred from Oracle to Eclipse are buildable, functional and usable.

Another significant change is the license. It’s the first version of GlassFish released under EPL 2.0 + GPL 2.0 with the GNU classpath extension.

And the third change is the modification of Maven coordinates of GlassFish components. To distinguish Jakarta APIs from Java EE APIs we changed their Maven coordinates from javax to jakarta and released new versions. The full list of components used in GlassFish 5.1 can be found here.

In addition to delivering the software we have also learned:

  • How to use Eclipse Development Process to elect committers, submit projects for release reviews, etc.
  • How to use Eclipse build infrastructure to setup build jobs, release components to staging repository and to Maven Central
  • How to communicate with different project teams and work together to achieve shared goals
  • And much more…

The next step for the Jakarta EE community is to complete the Jakarta EE specification process, create Jakarta EE specifications that correspond to all the Java EE specifications and approve all these specifications through the specification process.  That process will no longer require a Reference Implementation, but it will require at least one Compatible Implementation. We hope the community will ensure that Eclipse GlassFish is Jakarta EE 8 compatible and will remain a compatible implementation as the Jakarta EE specification evolves in the future.

It took us more than a year to deliver this release. A huge amount work has been done and we wouldn’t have completed it without community help and support. I would like to say thanks to all people who participated in this release.

Eclipse GlassFish 5.1 integrations finished!

We have a Christmas gift from Oracle Prague team. After weeks of hard work EclipseLink and Jersey project have been integrated to Eclipse GlassFish 5.1. Now we have all EE4J components integrated and integrations project finished: https://github.com/orgs/eclipse-ee4j/projects/6

It’s a huge step forward! We are very close to Eclipse GlassFish final release planned in January 2019. But there is still work to do. Now the goal is to produce a green CTS run. The progress can be tracked here: https://github.com/orgs/eclipse-ee4j/projects/8

Merry Christmas!

First year of Eclipse EE4J

The idea of transferring Java EE sources to the Eclipse Foundation was announced at the last Oracle JavaOne conference. The year has passed and in this article I will try to summarize what was done during this year and where we are now.

First of all, I am happy to announce that

Eclipse GlassFish RC1 is released!

It’s available for download here. This release is not final. It’s a milestone release with a purpose of indicating progress and providing developers the preview of the final product to play with, test it and provide feedback.

No doubt it’s a platinum trophy for the Jakarta EE community and we expect that Eclipse GlassFish sources will become the basis for an implementation of the Jakarta EE specifications.

It took us a year to achieve it. We transferred projects one by one from Oracle Java EE repositories and it was a challenging process. We had to go through a bunch of approvals on Oracle and Eclipse side. You can read more about it here.

There are currently 39 projects created and 88 repositories transferred.

I collected the information about when project sources were transferred on the picture below.

From Java EE to Jakarta EE (EclipseCon EU 2018).png

As you see we started with EclipseLink and Yasson, which were already at Eclipse Foundation, but under RT project. The first projects which were transferred from Oracle GitHub were JSONP, JMS, WebSocket and OpenMQ. It was done in January 2018. GlassFish repository and CTS/TCK repositories were transferred in Sep 2018.

Most of projects have the EPL 2.0 license, but some of them were transferred under the more permissive EDL license. This is true for projects that shared their codebase with the JDK in the past, such as JAXB and JAX-WS.

Now I would like to provide you some vision about the volume of work done. Let’s take a look at the Java EE codebase. Some projects (like most of the API projects) are relatively small. Implementations are usually much bigger and the TCK codebase is huge.

To be more precise, Java EE source-code contains over 5.5 million lines of code and over 2.2 million lines of comments in more than 61,000 files. For comparison, it’s around the same as the server side of World of Warcraft and the Linux Kernel 2.6.0.

CTS/TCK contains over 4.6 million lines of code and over 1.1 million lines of comments in more than 34,000 files. It’s comparable with the codebase of Windows NT 3.1 and Photoshop CS6.

In total we transferred 13.5 million lines of code in 95k files.

Screen Shot 2018-10-19 at 22.58.58.pngBased on data provided by https://informationisbeautiful.net

It’s worth mentioning that TCK/CTS sources were closed. It’s the first time the community has seen it and started contributing.

A lot of work is done, but there are still things to do. Here is a current status of projects from Eclipse EE4J web site:

Screen Shot 2018-10-19 at 23.02.01.png

The above graph charts the following progress:

  • 20% Project Proposal has been posted for community review
  • 40% Project committers and resources have been provisioned
  • 60% Initial Contribution provided to the Eclipse IP Team
  • 80% Initial Contribution Pushed to Git Repository
  • 100% Project has engaged in its first Release Review

Not all projects are at 100% yet. Most of the projects are still need to pass the release reviews and release the first Eclipse version. This work is in progress and it goes well so far. The community is highly involved. I counted people having more than 5 commits/bug reports and there are

more than 80 active contributors

from different vendors including Oracle, IBM, Red Hat, Payara, Tomitribe and others.

I created two pie-charts demonstrating how different vendors are participating in EE4J projects.

The first chart is demonstrating committers per organization. It represents 213 committers in total. If the employer of the person is not defined, they were assigned to At Large group.

Screen Shot 2018-10-19 at 23.03.22.png

The second chart demonstrated project leads by organization.

Screen Shot 2018-10-19 at 23.04.09.png

In order to achieve our goals the activity and participation levels must be kept high. The main goal currently is completing Java EE 8 certification and releasing the final version of Eclipse GlassFish.

The following is the current schedule:

Sep 21 — All code required for GF build contributed.
Sep 23 — Eclipse GlassFish builds.
Oct 1 — Java EE 8 CTS testing. Running CTS tests on Eclipse GlassFish.
Oct 22 — Eclipse GlassFish 5.1-RC1 milestone release.
Oct 29 — CI/CD release pipelines completed.
Nov 5 — Dependencies updated. All projects are released to OSSRH and have dependencies to Eclipse version of other components.
Nov 30 — Release Review completed.
Dec 14 — Eclipse GlassFish 5.1 release. All CTS tests are passed.

So far we are on schedule. We need to keep up the cadence and make a final push to release the final version of Eclipse GlassFish on Dec 14, 2018.

At the end of the article I would like to say thanks to the community and vendor support Jakarta EE has received. While Oracle is making the bulk of contribution effort, it will take a community to continue evolving and enhancing Jakarta EE. In addition to Oracle, this release will be delivered with assistance from Payara, Tomitribe, Red Hat, IBM, and various independent community members. We are very pleased to see this community come together and we look forward to further growth in the coming months.

Also, I would like to use this opportunity and invite people to participate in Jakarta EE efforts. This is the interesting time, don’t miss it!