GraalVM Native Image: SLF4J, Logback, Netty, InetAddress & Initialization Errors Despite Proper Configuration

[vinaykumarpandey]

I’m encountering an error while building a GraalVM native image for a Spring Boot application in multimode setup. The error indicates that an object of type org.slf4j.helpers.SubstituteLoggerFactory is found in the image heap, but the class is not initialized at build time.

Environment:

• Spring Boot: 3.4.4
• Couchbase: 3.4.4
• Couchbase SDK: 3.6.3
• Gradle: 8.1.3
• GraalVM: 23.0.2
• Native Image Plugin: 0.10.2
• SLF4J: Forced to 2.0.17
• Logback: Forced to 1.5.18

Dependency Resolution Strategy:
I’ve explicitly managed transitive dependencies using Gradle’s resolutionStrategy to force compatible versions of Netty, SLF4J, and Logback, as shown below:

eachDependency { details ->
if (details.requested.group == 'org.slf4j') {
details.useVersion '2.0.17'
}
if (details.requested.group == 'ch.qos.logback') {
details.useVersion '1.5.18'
}
}
Build Args:
I already include a comprehensive list of --initialize-at-build-time arguments, including:

--initialize-at-build-time=org.slf4j.helpers.SubstituteLoggerFactory
--initialize-at-build-time=ch.qos.logback.classic.Logger
--initialize-at-build-time=ch.qos.logback.core.*
--initialize-at-build-time=com.fasterxml.*
--initialize-at-build-time=com.azure.core.*
...
And also runtime initializations for Netty and JDK networking classes.

Error:
Despite including --initialize-at-build-time=org.slf4j.helpers.SubstituteLoggerFactory, I still get this error:

Build resources:

• 12.09GB of memory (75.6% of 16.00GB system memory, determined at start)
• 10 thread(s) (100.0% of 10 available processor(s), determined at start)
  [2/8] Performing analysis... [] (20.0s @ 1.00GB)
  15,616 reachable types (80.5% of 19,403 total)
  19,996 reachable fields (60.3% of 33,162 total)
  9,740 reachable methods ( 7.6% of 128,606 total)
  12,766 types, 4,443 fields, and 7,520 methods registered for reflection

Fatal error: com.oracle.graal.pointsto.constraints.UnsupportedFeatureException: An object of type 'org.slf4j.helpers.SubstituteLoggerFactory' was found in the image heap. This type, however, is marked for initialization at image run time for the following reason: classes are initialized at run time by default.
This is not allowed for correctness reasons: All objects that are stored in the image heap must be initialized at build time.

You now have two options to resolve this:

1. If it is intended that objects of type 'org.slf4j.helpers.SubstituteLoggerFactory' are persisted in the image heap, add

   '--initialize-at-build-time=org.slf4j.helpers.SubstituteLoggerFactory'

to the native-image arguments. Note that initializing new types can store additional objects to the heap. It is advised to check the static fields of 'org.slf4j.helpers.SubstituteLoggerFactory' to see if they are safe for build-time initialization, and that they do not contain any sensitive data that should not become part of the image.

2. If these objects should not be stored in the image heap, you can use

   '--trace-object-instantiation=org.slf4j.helpers.SubstituteLoggerFactory'

What I've Tried

• Ensured consistent dependency versions:
Aligned SLF4J 2.0.17, Logback 1.5.18, and Netty 4.1.119.Final to avoid transitive conflicts, using Gradle's resolutionStrategy.
• Configured build-time initialization for known problematic classes, including:
  • org.slf4j.helpers.SubstituteLoggerFactory
  • ch.qos.logback.*
  • io.netty.resolver.dns.*
  • java.net.Inet*
• However, the approach (Configured build-time initialization for known problematic classes) has become unsustainable, as the list of classes requiring --initialize-at-build-time or --initialize-at-run-time continues to grow only reactively based on errors during the native-image build.
This results in ongoing conflicts between runtime and build-time initialization for common libraries (e.g., logging and networking)
• Used the GraalVM agent to generate native configuration metadata and placed the output under META-INF/native-image.
• Followed GraalVM and Spring Native documentation, including known hints, logging setup, and reflection guidance.

My Questions

1. Why do classes like SubstituteLoggerFactory, ch.qos.logback.classic., java.net.InetAddress, io.netty.resolver.dns., etc., still cause runtime or build-time initialization issues despite being explicitly flagged while creating spring native image (./gradlew clean :moduleName: nativeCompile -x test)?
2. Are there known compatibility issues between SLF4J 2.0.17, Logback 1.5.18, Netty (4.1.119.Final), and GraalVM 23.0.2?
3. Are there any additional configuration flags, hints, or best practices required to properly configure SLF4J and related dependencies for GraalVM native-image builds

Any help or insight would be appreciated. Thanks!

[selhagani]

Hi @vinaykumarpandey,

Thank you for reaching out to us.

There is a newer version of GraalVM which is GraalVM for JDK 24 Community 24.0.1 that you should use which you can find here https://github.com/graalvm/graalvm-ce-builds/releases/ . Please try testing with it and if the issue still persists, could you also please specify which OS version you are encountering this issue on?

To address your question, I think if the the issue persists, it could be because there might be another conflicting --initialize-at-run-time flag somewhere in your app that causes this issue. Also using the tracing agent and running all the necessary tests to cover the functionalities of your application should create accurate configuration files. Are you seeing the same error even after doing this? If so then could you please share a concise reproducer with us alongside the steps needed to encounter the issue? Thank you.

[vinaykumarpandey]

Thank you @selhagani for your detailed response and suggestions.

At the moment, I’m still using GraalVM 23.0.2 and haven’t yet upgraded to version 24.0.1 — I’ll review the release notes and plan to test with the newer version as recommended. For reference, I’m running the application on macOS Sonoma.

As for testing, I’m currently skipping tests during the native image build (using -x test in Gradle) and not executing full test coverage during the agent tracing phase. Instead, I’ve enabled the GraalVM agent and manually invoked major API endpoints to capture the necessary metadata. While the application builds and runs successfully, I continue to encounter initialization issues during native image generation, particularly related to logging and networking — most notably involving SubstituteLoggerFactory and LoggerContext. I’ve enforced specific versions for SLF4J (2.0.17), Logback (1.5.18), and Netty (4.1.119.Final) to eliminate transitive dependency conflicts. Additionally, the application uses Splunk logging, which I suspect might also be contributing to the issue.

I plan to revisit the process with full test execution during agent tracing to ensure comprehensive metadata generation. If the issue persists even after upgrading and refining the setup, I’ll prepare a minimal reproducible example with the steps needed to reproduce the error. Thank you.