This is my personal experience while trying to push Java to the edge of my requirements of a Cloud-native environment. So these were the myths that are afloat about Java (or why Java is not cloud-friendly)
- It is heavy
- It is slow
- It is not up-to-date
So here is my latest attempt to burst all those myths with a tailor made stack for any future Java micro-services I develop - OpenJDK11, Helidon MP, GraalVM, and Podman.
What is Helidon?
Helidon is a lightweight micro-service library for Java, which lets you write fast, lean, and scalable Java applications. It comes in two variants - Helidon SE, and Helidon MP. I'm not sure what the SE means, but I call it "Super-Efficient" - yes, it's ultra small, and ultra fast. But Helidon SE might not be for everyone since it's reactive-first, leverages the builder model everywhere possible. So it might be attractive to the Kotlin-fanatics.
Helidon MP however, is what steals the show. It's standards-based, and directly inherits the Jakarta EE MicroProfile specification. Though it might not seem very lucrative at first, it means that your application stands on the shoulders of the enterprise giants like Oracle WebLogic, IBM WebSphere etc. Microprofile also is vendor-agnostic. So even if you start your application with Helidon MP, you can easily migrate to IBM OpenLiberty, Payara Micro etc. It really is a commendable position taken by Oracle, IBM, Payara etc. to let developers choose the best framework for their application, instead of imposing a vendor lockdown. I assume the world does not need anymore lockdowns at this point.
Show me the code, duh
Right to it. Here is my neofetch
output
And here's my Maven setup
Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f)
Maven home: /maven/current
Java version: 11.0.7, vendor: Oracle Corporation, runtime: /java/11.0.7-open
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "5.6.14-300.fc32.x86_64", arch: "amd64", family: "unix"
Getting a quick Helidon MP project setup is as simple as shamelessly using their stock Maven archetype
mvn archetype:generate -DinteractiveMode=false \
-DarchetypeGroupId=io.helidon.archetypes \
-DarchetypeArtifactId=helidon-quickstart-mp \
-DarchetypeVersion=2.0.0-M3 \
-DgroupId=io.helidon.examples \
-DartifactId=helidon-quickstart-mp \
-Dpackage=io.helidon.examples.quickstart.mp
Next, it's time to jazz it up
HTTP/2 support
## Add the following line in resources/META-INF/microprofile-config.properties
server.experimental.http2.enable=true
Custom JRE image
If you've been informed of one of the awesome features included in JDK9, it's the jlink
utility, which creates a custom JRE image, just enough to run your Java application (works for both JAR and WAR packages!)
mvn package -Pjlink-image
Native Java application!
Yep, not kidding. GraalVM allows you to create native Java binaries, and run them independently as shell executables.
Make sure you set your GRAALVM_HOME
environment variable to the path of your GraalVM installation. Here's mine.
$ $GRAALVM_HOME/bin/java --version
openjdk 11.0.7 2020-04-14
OpenJDK Runtime Environment GraalVM CE 20.1.0 (build 11.0.7+10-jvmci-20.1-b02)
OpenJDK 64-Bit Server VM GraalVM CE 20.1.0 (build 11.0.7+10-jvmci-20.1-b02, mixed mode, sharing)
So GraalVM is your off-the-shelf JDK, plus some awesome polyglot capabilities. For the purposes of this article, I had to install the native-image
extension for GraalVM
$GRAALVM_HOME/bin/gu install native-image
Next, just run Maven with the native image profile
mvn package -Pnative-image
So let me tell you how thin we made the application during this process.
The above images are all JakartaEE standard, Cloud-native and Kubernetes-ready!
Needless to say, I'm very interested to see what future lies ahead of the MicroProfile native frameworks. Hope this post has peeked your interest in Helidon, and GraalVM. Feel free to drop your comments or any suggestions!
Top comments (1)
What's the actual app? π€·ββοΈ