Which alternatives could be used to make an api with GraalVM
This blog post is the first of many on native compilation of Java API.
Container density problem
In the first place, why would we want to use GraalVM to develop an API with Java. It’s simple, we love Java. It has been here for 25 years and it still evolves to meet enterprise needs. But in comparison with other languages, Java need a JVM to run so in addition to our program we need to add this JVM in our container. So the container density problem arises. Indeed, the main Java competitors are lighter than Java and a standard JVM. What does it mean? It means that with the same resources we can’t deploy as many Java microservices as we could with Go or NodeJs microservices.
So, we can’t have as many Java microservices as we would have with Go or NodeJS microservices.
What should we do? Move our development using non-JVM based languages, which eventually will require a shift in development skills. One could take this approach if losing productivity is not an issue along with a shift in the development paradigm but fortunately for JVM lovers, we have GraalVm to the rescue. GraalVM allows us to compile our code specifically to the destination container and remove as much unnecessary code as possible.
The solution using Java : GraalVM
GraalVM is a VM and a JDK based on OpenJDK. The first production-ready version (19.0) was released in May 2019. It can be used for other languages such as Javascript, Ruby C and C++ but for our use case we are gonna stick with Java only.
With Ahead Of Time (AOT) compilation, our executable is gonna be removed of the code that we don’t need in our executable. Meaning the code in the frameworks and the JDK that is not needed in our final executable.
Does it mean we don’t use any VM for our native executable. It does not, our final executable contains the SubstrateVM a small JVM without all the optimization that we have in a standard JVM.
So the AOT compilation is not magical, it does come at a price :
-
Dynamic classloading ⇒ not supported
-
JVMTI, JMX and other VM interfaces (no agent) ⇒ not supported
-
Reflection ⇒ partially supported
-
No JVM optimization
More details on the SubstrateVM limitations
To compile an executable with GraalVM it can be complicated to parameter. By example, GraalVM can’t detect the code called using reflection.
So in order to use the power of GraalVM with all the frameworks which help us to be productive with Java, we need use tools which are already GraalVM ready.
Tools at our disposal
A rapid search on the web gives us a list of five :
Helidon
Helidon was an internal Oracle project (J4C ⇒ Java for cloud) which implement the Microprofile specification. The first version was released in February 2019.
Quarkus
Quarkus is a Red Hat project released in March 2019 which implement the Microprofile specification. There has been lot of traction on Quarkus since the beginning.
I had the chance to make a talk on Quarkus inside NBC in April 2020 following by a workshop for the Montréal Jug in June 2020.
Micronaut
Micronaut is a project released in May 2018. It seems to have a foundation behind it and is pretty active.
Microprofile
Micro Profile is more a specification and the starter can generate the project for a specific runtime :
-
Quarkus
-
Helidon
-
Open Liberty
-
Payara Micro
-
Thorntail V2
-
Wildfly
-
KumuluzEE
It’s backed by the Eclipse Foundation.
Spring Boot
Spring Boot is the most ancient (released in April 2014) and yet the one of the less mature to be used with native compilation, but it seems to progress really fast on that end.
Conclusion
We have many options. I will write about some of them in my next blog posts. In my next blog posts, I will develop a Java API using Quarkus, Micronaut or Spring Boot with a PostgreSQL database behind it.