Anybody who was ever even remotely involved in R&D activities knows that the path to true revelations and discoveries is riddled with endless rabbit holes, most of which never help us reach anything useful. But every now and then, one of these rabbit holes leads us to something useful, reminding us why we ventured out for the adventure in the first place.
This is precisely what happened as a part of our Project Klokwrk – despite all odds, we have found a way to package the Groovy application as a GraalVM native image! And you know what’s even better? We could have a full, exclusive study exaplaining how we did it delivered directly to your inbox.
What’s the big deal, you might be wondering…
GraalVM is a fascinating open-source project. It started as an effort to provide a high-performance polyglot virtual machine. However, in the JVM ecosystem, it seems that most of the community interest comes from GraalVM ability to create high-performance, low-footprint, Ahead-Of-Time (AOT) compiled native images (provided as part of SubstrateVM sub-project).
Many popular JVM frameworks (for example, Micronaut, Quarkus, Helidon, and even Spring Framework) adopted GraalVM native image support for statically compiled languages like Java and Kotlin. Unfortunately, some other popular JVM languages, like Groovy, are left-out from out-of-the-box support because they use reflection extensively for many of their features. One simply has to wonder – can these languages also enjoy the benefits of GraalVM native image support?
So, what did we do?
As Klokwrk uses Gradle as a build tool, we have built a utility to help us debug Gradle build scripts, 3rd party plugins, and internal classes. This utility, called klokwrk-tool-gradle-source-repack, is a CLI (command-line) utility built on top of Groovy, Micronaut, and picocli. It only seemed natural to see if it was possible to package it as a GraalVM native image.
Challenge accepted!
With Micronaut’s support for GraalVM native images and provided integration with picocli, we already had a great starting point. We “only” needed to add Groovy in the picture. This was no easy feat, but with sufficient understanding of the internal workings of particular technologies, we have managed to pack a Groovy application as a GraalVM native image, proving that building a GraalVM native image for the Groovy application is very much possible.
Wait, but how?
To find out how we managed to pack a Groovy application as a GraalVm native image, leave us your e-mail address and we will have a full, exclusive study “Taking a Groovy on GraalVM native image journey” delivered directly to your inbox. Don’t miss out!
Related News
