Oracle has released Project Helidon 3.0, featuring support for JDK 17, Jakarta EE 9.1, and MicroProfile 5.0. Also included in this release is the new Helidon Starter for generating custom Helidon applications, an updated command-line tool, and a security hardening of Java serialization through JEP 290: Filter Incoming Serialization Data.
Helidon is a cloud-native Java framework for microservices, supporting both imperative and reactive applications. Due to security concerns, Helidon doesn't use Java serialization and disables it by default for applications. Helidon 3.0 also improves the routing of reactive applications.
Upgrading to version 3.0 is straightforward for reactive applications. Imperative applications, on the other hand, "need to change to jakarta.* dependencies and address backwards compatibility issues."
Helidon recently demonstrated early support for the virtual threads of Project Loom with Helidon Níma. Níma is part of Helidon 4.0, scheduled for a formal release by the end of 2023. Virtual Threads (preview) and Structured Concurrency (incubator), under the auspices of Project Loom, were delivered in JDK 19.
Helidon has officially supported native Java with GraalVM in production for years, like Quarkus and Micronaut. Spring Boot 3.0, planned for a GA release in late 2022, will add built-in native Java support.
InfoQ spoke to Helidon project lead Dmitry Kornilov, director of software development at Oracle and Project Helidon lead, about this project.
InfoQ: Since the release of Spring 1.0 in 2004, only one significant new Java framework has appeared: DropWizard in 2011. All that changed when Micronaut and Helidon were introduced in 2018 and Quarkus in 2019. Why do you think that happened?
Dmitry Kornilov: Microservice development was growing in popularity back then, increasing demand for lightweight cloud-native Java microservice frameworks. These new frameworks have a much smaller footprint than Java/Jakarta EE application servers and are optimized for modern microservices development. Helidon provides an open implementation based on the MicroProfile standard that gives developers compatibility and portability.
InfoQ: How is writing a Java microservice with Helidon different from writing it with Spring Boot?
Kornilov: The declarative development experience with Helidon is identical to Spring Boot and Quarkus. But the runtime is different: we are trying to make Helidon as effective as possible by reducing the number of third-party dependencies and through various performance optimizations.
InfoQ: Helidon supports imperative (Helidon MP) and reactive programming (Helidon SE). In your estimation, what percentage of Helidon users pick reactive programming?
Kornilov: I don't have statistics, but I estimate 30 percent. It's a trade-off: If your focus is on business logic, you can use imperative programming with Helidon MP. If you need the highest possible performance and are willing to invest in the additional complexity of asynchronous development, use the reactive model of Helidon SE. Many users have chosen Helidon SE for that reason.
InfoQ: Helidon allows deploying Java applications to native executables through the GraalVM Native Image compiler. These native executables start faster and use less memory than regular Java applications. In your experience, what percentage of Helidon users runs native Java in production?
Kornilov: I don't have the numbers. I think native Java is a great choice for applications requiring fast startup time, like serverless functions. For long-running services, which is the most common use case for Helidon applications, HotSpot JRE is preferred because of its excellent runtime optimization.
Helidon also provides an option to build a JLink image with smaller footprint and faster startup time.
InfoQ: How do you think Helidon compares with Quarkus and Micronaut?
Kornilov: Only Helidon supports all features of the Jakarta CDI dependency injection specification in native Java, including portable extensions. Helidon uses Red Hat's Weld CDI implementation and improved it for native Java.
Micronaut uses its own injection mechanism and doesn't support CDI. Quarkus' implementation doesn't support some CDI features, such as portable extensions, but is optimized for build-time processing.
InfoQ: If there's one thing you could change about native Java with GraalVM, what would that be?
Kornilov: I asked the Helidon developers for suggestions. First, it would be great to have public APIs for custom extensions such as features, substitutions, etc. There are private APIs for that, but it's a bad practice to use them. Another suggestion is giving more informative error messages to help fix compatibility issues.
InfoQ: In which areas do you see native Java used most with Helidon? And where is native Java not suitable for Helidon users?
Kornilov: Helidon fully supports GraalVM Native Image. We recently published some Helidon success stories (more are coming). Oracle CX Industry Framework (CXIF) uses Helidon with native Java:
Together with Helidon, GraalVM is also a critical technology to the CXIF architecture. CXIF uses GraalVM Native Image to create minimum-size, precompiled executable images of its microservices. These images are further compressed using UPX compression to yield Docker container images of size <50MB for use with Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE). This enables extremely fast startup time for containerized microservices, allowing CXIF to dynamically start containers running microservices on-demand as requests come in!
More details on this latest release may be found on this GitHub repository. Also, developers interested in a deep-dive of native Java may peruse through this InfoQ six-article series.