This blog post is the first of many on native compilation of Java API.
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.
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.
A rapid search on the web gives us a list of five :
Helidon was an internal Oracle project (J4C ⇒ Java for cloud) which implement the Microprofile specification. The first version was released in February 2019.
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.
Micronaut is a project released in May 2018. It seems to have a foundation behind it and is pretty active.
Micro Profile is more a specification and the starter can generate the project for a specific runtime :
It’s backed by the Eclipse Foundation.
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.
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.