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.

[sgammon]

The answer is actually pretty spot-on. You will need to use --initialize-at-run-time or one of the other techniques mentioned.

[sgammon]

@credmond Of course, it's also an option to just use Logback if you have enough trouble with TinyLog. I've never used it so I can't say if it's some other issue. Logback has worked fine for us under Native Image for a long time. Since you are already using SLF4J that may be a very easy switch.

[credmond]

It is not spot on, it's a copy and paste from AI of general stating-the-obvious noise, You're both missing the point of the problem.

You cannot override a library config, for example, that sets --initialize-at-build-time=ClassA with --initialize-at-run-time=ClassA. If I could, I wouldn't have posted this discussion.

That's also why I said this:

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.

I literally explained that GraalVM will not allow me to do the most obvious thing (i.e., your spot-on advice).

Using Logback isn't a solution, it's a workaround to hide a problem that can just re-appear in similar circumstances.

[Bulletdev]

The core issue is that the ProcessHandleImpl is being reflectively accessed during initialization, which conflicts with GraalVM Native Image's static compilation model. In Native Image, classes that need to use reflection, especially for runtime-specific operations like process handling, require special configuration.
Here are a few approaches you could consider:

Native Image Configuration

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

Reflection Configuration
Create a reflection-config.json in your META-INF/native-image directory:

[
{
"name": "java.lang.ProcessHandle",
"methods": [
{"name": "current", "parameterTypes": [] }
]
}
]

Resource Configuration
Sometimes you might need a native-image.properties or native-image.args file:

-H:ReflectionConfigurationFiles=META-INF/native-image/reflection-config.json
--initialize-at-run-time=java.lang.ProcessHandleImpl

Potential Workaround in Tinylog
If possible, you might want to modify the ModernJavaRuntime class to make the ProcessHandle retrieval optional or conditional. Something like:

private static ProcessHandle getCurrentProcess() {
try {
// Only attempt if running on a compatible Java version
if (Runtime.version().feature() >= 9) {
return (ProcessHandle) ProcessHandle.class.getDeclaredMethod("current").invoke(null);
}
} catch (ReflectiveOperationException | UnsupportedOperationException ex) {
// Gracefully handle if process handle can't be retrieved
}
return null;
}

Dependency Exclusion
If tinylog is pulling in problematic runtime dependencies, you might need to exclude them:

org.tinylog tinylog-impl * *

[credmond]

You're not fooling (or helping) anyone.

[mkouba]

@credmond You can try to use --initialize-at-run-time=org.tinylog.runtime.RuntimeProvider, to ensure the RuntimeDialect#resolveDialect() (which triggers ProcessHandle#getCurrentProcess()) is initialized at runtime.

However, you'll also need to make sure the --link-at-build-time option is not used because some of the tinylog classes link Android types such as dalvik.system.VMStack.