Year: 2019

Helidon flies faster with GraalVM

dmitrykornilov ,

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 tenths 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

dmitrykornilov

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

dmitrykornilov , ,

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.