Add GraalVM native image build configurations

Description

Updated description:

After investigation + discussion with the Micronaut team, we decided in this ticket to include GraalVM native image configs in the driver jars to make native image generation as easy as possible.

The most important set of configs are related to the registration of all driver built-in implementations that are instantiated by reflection.

Initial description: Java driver 4.11.1 not compatible with GraalVM

I've been working on adding support for GraalVM for the Cassandra java driver in Micronaut. First I tried with driver version 4.9.0 and with the reflection configuration generated by the native agent everything works.
You can see the configuration here https://github.com/micronaut-projects/micronaut-cassandra/commit/d1766bfa2124207e32e8c7ad3c8ac48fc5801d12.

Then I've tried to upgrade the driver to 4.10.0 and my test application still works although I see some warning when creating the native image:

But then I've tried to update the driver to the latest version 4.11.1 and native image generation fails with the following error:

Adding --trace-class-initialization=com.datastax.oss.driver.internal.core.util.Reflection as suggested doesn't add any relevant information or helps in any way. I've also tried with the tracing agent but the generated configuration is like in previous versions.

Taking a look at the release notes it seems that maybe https://datastax-oss.atlassian.net/browse/JAVA-2917 has something to do with this error. Or maybe there is something else that was changed in that release.

If you want or need I can create easily a reproducer app that works with 4.9.0, show the warnings with 4.10.0 and fails during native image generation with 4.11.1.

Environment

Linux and GraalVM 21.1.0

Pull Requests

None

Linked issues

relates to

JAVA-2955

Remove Netty-JCTools exceptions for GraalVM native image

JAVA-2956

Add automated integration tests for GraalVM native images

resolves

JAVA-2777

Document "lessons learned" from Quarkus work for Graal users

Activity

Show:

Iván López July 29, 2021 at 3:32 PM

Awesome news! I’ve tried the changes from the PR and everything works perfect!

Thank you very much for doing this

Regards, Iván.

Alex Dutra July 29, 2021 at 2:12 PM

thanks for the feedback, this is really helpful for us. We are going to go with the approach of including everything. I updated the PR and we are now close to merging it. If you have time to test once more, that would be great, thank you!

Iván López July 29, 2021 at 8:10 AM

@Bret McGuire,

Thanks for the clarification, it’s great not need the jni library anymore

@Alex Dutra,

This is great news. The Micronaut Cassandra application I use for tests is 64.4 MB. With those numbers I think it’s totally worth it to include evertyhing so users don’t need to worry about anything.

Alex Dutra July 28, 2021 at 4:19 PM

I can make some tests with Micronaut so we can see how much the native image size grows in the different cases.

I just played with that myself. I tried to build the native image for a sample app of mine, using 2 of the strategies discussed before:

Register all driver impls:
1. 35 impls registered for reflection (+ 9 Netty-related classes)
2. The final image size was 45275584 bytes (45.28 Mb)
Register only default impls:
1. 11 impls registered for reflection (+ 9 Netty-related classes)
2. The final image size was 44685008 bytes (44.69 Mb)

The difference in size is 590576 bytes (591Kb).

The ratio in my case is 45275584 / 44685008 = 1.32 % growth. Obviously the ratio will vary depending on your base image size. But roughly if your app is 50Mb, you can expect a growth of ~1%. If it’s 100Mb, the growth would be around ~0.5%.

Bret McGuire July 28, 2021 at 3:56 PM

Hey , thanks for your reply! Your comments have been very helpful as we try to close in on a release of this functionality.

Regarding your question about libjffi…. you shouldn’t have any reason to include this lib in your resources anymore. We used to make use of this lib (and some of the other JNR/jffi infrastructure) for executing “native” operations within the driver but as of there’s no longer any need to do so. You should be very safe to remove any explicit declaration for that lib from your native images.