native-image support with Graal and native-image.properties

[doctorpangloss]

Consumers of Guava in a native-image built .jar would benefit from netty's approach with native-image.properties and org.graalvm.nativeimage.imagecode (see netty/netty#8192 and https://github.com/netty/netty/pulls?q=is%3Apr+svm for what this entails).

The core issue is some parts of Guava use JDK features that are not compatible with GraalVM's native-image feature.

Some objectives:

• native-image.properties file is included in the META-INF / jar artifacts of Guava to be used by native-image -jar user-shadow-jar.jar build pipeline.
• Reflection, proxy and JNI configuration files included in the META-INF and referenced by the native-image.properties.
• All of Guava can be initialized at build time using the native-image argument --initialize-at-build-time=com.google.

The biggest obstacle is some classes use native heap features which are not allowed for static initialization at build time. netty uses feature detection for this issue.

FAQ

Why is native-image valuable really?

Serverless applications and building Java applications for containers and mobile devices.

What are current workarounds?

• Static initialize only the specific Guava classes you need, and stop using the ones that are inherently incompatible. Usually the incompatibilities come from a transitive dependency on Objects which has an empty static initializer anyway. Repeatedly run native-image and add the classes it reports you need.
• Avoid anything that does native heap allocation like the cache classes.

How can I make this about Google Cloud support for Java?

native-image support in Guava would make it easier to use a common Google Java library for serverless / cloud functions.

[linghengqian]

What is the reason why this issue is blocked?