Red Hat and the GraalVM community recently announced the release of a new GraalVM distribution called Mandrel . This new distribution is expected to boost the Red Hat build of Quarkus, a recently announced addition to Red Hat Runtimes.
Quarkus is a native Java Kubernetes framework for the JVM and native compilation. Quarkus provides an efficient solution for running serverless Java applications, microservices, containers, Kubernetes, FaaS, or cloud applications. Mandrel is open source and available on GitHub, but it does not yet have a binary distribution.
According to a note from Mark Little, senior director of engineering at Red Hat, Mandrel can be described as a distribution of a standard OpenJDK with a specially packaged native GraalVM image.
The primary goal behind Red Hat's introduction of Mandrel is to improve the speed and efficiency of the Quarkus framework. It's a framework that offers local development with fast reloads and containerized or serverless distribution to cloud computing providers.
Quarkus focuses on the ability to build native executables that start faster and also reduce costs and operational resources in the cloud.
In fact, Red Hat explained that for Quarkus, the important element of GraalVM is its native image function , which produces native executables—a key feature for Java to be competitive in cloud-native workloads. Therefore, Mandrel allows GraalVM to be used alongside OpenJDK 11 on Red Hat Enterprise Linux and other OpenJDK 11 distributions.
According to Red Hat, the difference to the user is minimal, but for maintainability, prior alignment with OpenJDK 11 and GraalVM is essential.
“With Mandrel, Red Hat customers and the GraalVM community benefit from truly open development, and Red Hat can support its customers with proven mechanisms while giving back to the communities they trust to continue advancing the state. of the art of open source computing, "said the company, speaking about Mandrel.
In terms of performance, GraalVM stands out with a 50x faster startup time and 5x lower memory usage.
These different tests were done using an older version of the Quarkus framework against the Java HotSpot mode. Although this enhancement requires a longer compile time, it can be used in parallel with the deployment of Quarkus Lambda and Azure functions.
Furthermore, the Mandrel GitHub repository does not yet offer a binary distribution. Therefore, users compile the JDK themselves following the instructions. Additionally, software developer James Ward reviewed GraalVM in detail, outlining its performance benefits as well as some drawbacks, such as applications that rely on reflection.
According to him, this creates a problem for native GraalVM images because reflection occurs at run time, making it difficult for an AOT (early bird) compiler to determine execution paths.
When it comes to apps that don't need to think, the Quarkus home page points directly to the advantage: 12MB of RAM versus 73MB (a decrease of 83%) and 0.016 seconds in the first response versus 0.943 (a decrease of 98 %).
Developers can now use Mandrel with their own build , or they can rely on the GraalVM community or any distribution of JDK 11 and above. Others say these native Java frameworks don't really work and shouldn't become an industry standard.
According to them, it's not a general-purpose technology where you can take an existing Java application and make it native. This won't work, even for applications written using a library from the vast Java ecosystem.
The latter believe that various framework providers are betting on the fact that most Java applications are HTTP / ORM / JSON applications, in addition to measures and security, etc.
If you want to know more about it, you can consult the following link.