Shortly after the release of Helidon 1.0, Oracle announced Helidon support for GraalVM that converts Helidon applications to native executable code via the native-image utility.
Originally named J4C (Java for Cloud) and first introduced in September 2018, Helidon was designed to be simple and fast, and is comprised of two versions: Helidon SE and Helidon MP. Helidon SE features three core APIs -- a web server, configuration, and security -- for building microservices-based applications. An application server is not required. Helidon MP MicroProfile 1.2 for building microservices-based applications with the supported MicroProfile APIs.
GraalVM, created by Oracle Labs, is a polyglot virtual machine and platform that may be integrated into Helidon applications. GraalVM is comprised of Graal, a just-in-time compiler written in Java, SubstrateVM, a framework that allows ahead-of-time compilation of Java applications into executable images, and Truffle, an open-source toolkit and API for building language interpreters.
Only Helidon SE applications may take advantage of GraalVM due to the use of reflection in CDI 2.0 (JSR 365), a core MicroProfile API. Therefore, Oracle Labs decided not to include GraalVM support for Helidon MP.
The Helidon SE quickstart example includes a Maven goal for the GraalVM native-image utility and Docker files to convert the application to native executable code. This example has been tested with Helidon 1.1.2 and GraalVM 19.1.1, the latest versions of each.
$ export GRAALVM_HOME=/usr/local/bin/graalvm-ce-19.1.1/Contents/Home
$ mvn package -Pnative-image
This will generate the usual JAR file (helidon-quickstart-se.jar) and the native image executable (helidon-quickstart-se) each of which may be launched as follows:
$ java -jar target/helidon-quickstart-se.jar
$ ./target/helidon-quickstart-se
An installation of GraalVM is not required to use the Docker profile:
$ docker build -t helidon-native -f Dockerfile.native .
$ docker run --rm -p 8080:8080 helidon-native:latest
As shown below, the web server is started with native executable file, helidon-quickstart-se, generated by GraalVM.
Dmitry Kornilov senior software development manager at Oracle, discussed the use of native executables on long-running applications, writing:
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.
Kornilov spoke to InfoQ about Helidon and GraalVM including more details regarding long-running vs. short running applications:
InfoQ: Please explain why performance in long-running applications is better with a traditional JVM over a native executable built with GraalVM.
Dmitry Kornilov: Performance is improved because of JIT compilation and runtime performance optimization. JVM has runtime information that is not available to the static compiler. It uses this information to continuously optimize applications and run more efficiently. Runtime optimization takes some time. Statically compiled applications demonstrate higher performance immediately after the application has started. But over time, when runtime optimizations are performed, JVM-based applications start demonstrating higher performance.
Native images are perfect for short-running applications like functions where start time is critical. For long-running services, where start-up time is not so critical, JVM with runtime optimization is better. Also, don't be fooled with start-up times. My sample application starts up 1½-2 seconds slower on my notebook than the same application compiled as a native image. However, the difference is negligible when comparing it to Kubernetes pod start-up time, for example.
InfoQ: Helidon currently supports MicroProfile 1.2. With the recent release of MicroProfile 3.0, is there a plan to incrementally achieve the goal of supporting a more recent version of MicroProfile?
Kornilov: MicroProfile 2.2 support is already in master and we are making some final tuning adjustments before the release. MicroProfile 3.0 has some backwards incompatible changes, so we will possibly need to release a new major version of Helidon to support it. We already have OpenAPI 1.3 support and support for HeathCheck 2.0 is almost complete as well. Support for Metrics 2.0 requires more work and we are evaluating and estimating it now. I expect that we will add MicroProfile 3.0 support before the end of 2019.
InfoQ: What's on the horizon for Helidon?
Kornilov: There are many things we are working on. HTTP multipart and full HTTP/2 support are coming soon. We are also working on Helidon DB Client which will allow using JDBC databases the reactive way in Helidon SE.
We are also improving JPA and JTA support in Helidon MP and recently added Universal Connection Pool (UCP) support which includes cool continuity features. We just started working on reactive messaging and eventing support, but it's too early to talk about that now. By the way, there are several Helidon sessions accepted for Oracle Open World and CodeOne. If you are attending, don't miss these sessions as we'll be providing more details about Helidon features and future plans.
Resources
- Helidon Takes Flight by Dmitry Kornilov (September 7, 2018)
- Oracle Introduces Helidon - A Lightweight Java Microservices Framework by InfoQ (October 10, 2018)
- Helidon V1 Brings API Stability and MicroProfile 1.2 Support by InfoQ (March 12, 2019)
- Helidon Flies Faster with GraalVM by Dmitry Kornilov (April 17, 2019)
- GraalVM 19.0: the Anticipated GA Release by InfoQ (June 17, 2019)