Assisted Configuration agent does not consider META-INF/native-image files

[raphw]

I have added a native-image.properties file to my library to specify that its static initializers are to be run at build-time, not at runtime, as this is safe.

When running the assisted configuration agent, this agent detects all code that is run from these static initialization blocks and adds entries to reflect-config.json, whereas those entries are obsolete due to the static blocks being executed during build time. To make things worse, as there are classes generated in the static blocks, these classes cannot be found statically during the native-image phase, what fails the build if those entries are not manually removed. After removal from the generated reflect-config.json, everything works as expected.

During native-image execution, the native-image.properties file is respected, and I would expect that the agent makes the same consideration as the file is available from the libraries jar file.

I would suggest that the assisted support agent should scan for native-image.properties files available and check the stack trace to find if a discovery is triggered from a static initializer block, to then exclude such a discovery if the native-image.properties file suggests that the package is initialized at build time.

Does this sound like a reasonable extension?

[raphw]

To simplify the replication of the problem, I added a reproduction in sample.zip.

Running native-image -cp bb.jar:. Sample yields

Error: Error parsing reflection configuration in file:/home/rafael/foo/META-INF/native-image/reflect-config.json:
Could not resolve net.bytebuddy.utility.Invoker$Dispatcher for reflection configuration. Reason: java.lang.ClassNotFoundException: net.bytebuddy.utility.Invoker$Dispatcher. To allow unresolvable reflection configuration, use option --allow-incomplete-classpath

what can be avoided by deleting all entires in the net.bytebuddy namespace.

Note that there's a related issue to be solved to actually run the program where dynamic classes need to be stored. For now, this can be circumvent by adding the contents of dynamic.zip.

[oubidar-Abderrahim]

Thank you for reporting this, we will take a look into it and get back to you

[vjovanov]

I find this to be a great proposal; it will also reduce the image size.
I would still keep a flag that disables this functionality in the agent as we have a flag to ignore what is in the jar config as well.