Impossible to build native image with tinylog and well known libraries

[credmond]

Here's my issue, who has some advice? :)

I have a Maven project with some well-known dependencies specified (netty, azure-code for example), those dependencies have their own native-image.properties that have something like (note, build-time):

--initialize-at-build-time=ch.qos.logback.classic.Level,\
                             ch.qos.logback.classic.Logger,\
                             ch.qos.logback.classic.PatternLayout,\
                             ch.qos.logback.core.CoreConstants,\
                             ch.qos.logback.core.pattern.parser.Parser,\
                             ch.qos.logback.core.spi.AppenderAttachableImpl,\
                             ch.qos.logback.core.status.InfoStatus,\
                             ch.qos.logback.core.status.StatusBase,\
                             ch.qos.logback.core.util.Loader,\
                             ch.qos.logback.core.util.StatusPrinter,\
                             ch.qos.logback.core.util.StatusPrinter2,\
                             org.apache.log4j.Logger,\
                             org.slf4j.MDC,\
                             org.slf4j.LoggerFactory,\
                             org.slf4j.impl.StaticLoggerBinder,\
... etc

My project doesn't use logback firstly, it uses tinylog/slf4j. But because of the build-time initialization configuration in these libs, I'm forced to include (via determining through the errors), a bunch of tinylog classes in my project's configuration as build-time initialisation too, presumably because the SLJ4J bindings all lead back to tinylog and so they all need to be built-time.

Although I'd rather not have to do all of this hackery, I thought maybe all fine, as a once off. Until I eventually am forced to try to add this as a build-time init: java.lang.ProcessHandleImpl.

Why? Well tinylog has a class that's being instantiated during init'ing via the logging providers -- and that class is called org.tinylog.runtime.ModernJavaRuntime, and it has this:

private final ProcessHandle currentProcess = getCurrentProcess();

private static ProcessHandle getCurrentProcess() {
	try {
		return (ProcessHandle) ProcessHandle.class.getDeclaredMethod("current").invoke(null);
	} catch (ReflectiveOperationException ex) {
		InternalLogger.log(Level.ERROR, ex, "Failed to receive the handle of the current process");
		return null;
	}
}

And this seems to be used to return a process ID to the logging provider registry, or whatever.

Regardless, I cannot add ProcessHandle or ProcessHandleImpl with build-time init config, as I get this:

com.oracle.svm.core.util.UserError$UserException: Incompatible change of initialization policy for java.lang.ProcessHandleImpl: trying to change BUILD_TIME from command line with 'java.lang.ProcessHandleImpl' to RERUN for JDK native code support via JNI

...so I'm completely stuck. And I honestly don't want to go down to the level of adding dozens of classes, anyway.

What's really frustrating is that I only want to access a few classes in these libraries -- I don't care about their own logging or most of their functionality. I don't know why they have such complex build-time configurations, but I bet it's related to logback and logging. And I cannot override or ignore the native-image.properties config (e.g., make everything run-time and see what happens). If you try that, GraalVM complains about that.

What can I do here? Of course I fork, tweak the config, and re-publish the libraries as my own, but that's not a feasible solution, even if it worked (which it might not).

[Bulletdev]

It sounds like you're facing a challenging issue with the build-time initialization configuration in your Maven project, especially with dependencies that have their own native-image.properties settings. Here are a few strategies you might consider to address this problem:

1. Custom Initialization Configuration
   You can create a custom native-image.properties file for your project to override the default settings provided by the dependencies. This file should be placed in the META-INF/native-image directory of your project. You can specify your own initialization settings to avoid conflicts.

2. Reflection Configuration
   If certain classes are causing issues due to reflection, you can create a reflect-config.json file to specify how reflection should be handled. This file can be used to configure which classes and methods should be accessible via reflection at runtime.

3. Substitution Classes
   GraalVM allows you to create substitution classes to replace problematic classes with your own implementations. This can be useful if you need to bypass certain initialization logic that is causing issues.

4. Excluding Unnecessary Dependencies
   If certain dependencies are not critical to your project, consider excluding them from your build. This can be done by modifying your pom.xml to exclude specific transitive dependencies that are causing issues.

5. Using GraalVM's --initialize-at-run-time Option
   You can use the --initialize-at-run-time option to specify that certain classes should be initialized at runtime instead of build time. This can help avoid issues with classes that have complex initialization requirements.

Example Configuration
Here is an example of how you might configure your native-image.properties file:

META-INF/native-image/native-image.properties

Args = --initialize-at-build-time=org.tinylog.runtime.ModernJavaRuntime
--initialize-at-run-time=java.lang.ProcessHandleImpl

6. Community and Support
   Consider reaching out to the community or support channels for the libraries you are using. They might have encountered similar issues and could offer solutions or workarounds.

Summary
• Custom Initialization Configuration: Override default settings with your own native-image.properties.

• Reflection Configuration: Use reflect-config.json to handle reflection.

• Substitution Classes: Replace problematic classes with your own implementations.

• Excluding Unnecessary Dependencies: Modify pom.xml to exclude problematic dependencies.

• Using GraalVM's --initialize-at-run-time Option: Specify runtime initialization for certain classes.

• Community and Support: Seek help from the community or library maintainers.

By carefully configuring your project and leveraging GraalVM's options, you should be able to resolve the initialization issues and build your project successfully. If you need further assistance, feel free to ask!

[credmond]

Pal, you just ripped that straight from ChatGPT. None of that helps or makes sense given what I said. Grow up.