Work with Third-Party Libraries
When building native images for your own projects, a common problem is how to work with third-party libraries for native image generation.
With Built-in Support
The best choice is for the library itself to provide GraalVM native image support. Some libraries already provide support for GraalVM native images. JAR files of these libraries have GraalVM build configurations below the resource location META-INF/native-image/. Usually we don't need to take further actions for this kind of libraries.
As shown in the picture below, JARs from Netty already have embedded GraalVM native image configurations.
Without Built-in Support
Given the huge number of Java libraries, it's likely that your project will use some libraries that don't provide GraalVM support. In this case, you have three options.
Wait
The first option is waiting for the library to provide support for GraalVM native image. Depends on the priorities and capacity of the library's maintenance team, this may take a long time.
For example, an issue was open for Flyway to provide native image support on 11 Sep 2020, this issue is still open now.
Rely on Frameworks
Even though the library doesn't support native image, popular frameworks may provide the support. For example, Quarkus and Micronaut both support Flyway. If the project uses one of these frameworks, you are good to go.
This only works when the library is popular enough.
For Spring Native, according to this comment, GraalVM will provide a native configuration repository to host configurations for different libraries. It's not clear when this feature will be implemented. Currently, Spring Native does't accept native image configurations for non-Spring libraries.
According to this comment, proper integration with will be provided by Spring Boot 3.
If a popular library doesn't provide built-in support for native image, we'll see code duplications for native image support in different frameworks. For example, Quarkus and Micronaut both have similar code for Flyway support.
Create Your Own
The last option is to provide your own support for the library. This also depends on the framework you are using. We can always use build configuration files and features provided by GraalVM SDK. Some frameworks provide abstraction layers on top of GraalVM SDK.
GraalVM SDK
Use build configuration files, features, and substitutions.
Quarkus
Write your own extension.
Spring Native
Use native hints.
Spring Native samples project shows how to provide support for Flyway.