-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Description
Hi!
I'm involved in the native effort which is going on in the Spring projects. Our goal is that a Spring (Boot) application works out of the box in a native image. Unfortunately it's not enough that we make our code native-ready, but all the libraries we are using have to support native, too. And this is why I created this issue: your great project is involved some of the Spring projects and we need your help.
Oracle has created the GraalVM and one of its features is the native-image tool, which allows compiling a JVM application into a native executable. This executable doesn't need a JVM to run, it starts faster and often consumes less memory. But this has downsides, as some dynamic features from Java are not supported without additional configuration. The biggest contenders are reflection, resources and proxies.
Luckily, a library can ship some JSON metadata in the META-INF/native-image/... directory which enables those features.
For libraries which don't (or can't) add the metadata in their JARs, Oracle has created the graalvm-reachability-repository, which contains this metadata outside of the libraries JAR file. In an ideal world, all of the metadata is moved into the JARs of the libraries, but until our world has reached its ideal state, this repository will be used.
There's already metadata for your library in this repository, but it would be great if in future this metadata would reside directly in your codebase. The big advantage is that if your code changes, the metadata can change along with it. Otherwise users would be broken until the graalvm-reachability-metadata is updated.
What do you think? Are you willing to put this metadata in your codebase? If you have more questions about native-image, please don't hesitate to ask.