ShutdownHook: NoClassDefFoundError

[jukzi]

Version

latest

Operating System

Linux/Unix, MacOS, Windows

Bug description

at the end of each platform build an error is logged

Actual behavior

exception

Expected behavior

no exception, load the text while classloader available or inline string "Cleanup during JVM shutdown failed"

Relevant log output

Error: Exception in thread "Thread-3" java.lang.NoClassDefFoundError: org/eclipse/jgit/internal/JGitText
	at org.eclipse.jgit.internal.util.ShutdownHook.cleanup(ShutdownHook.java:85)
	at java.base/java.lang.Thread.run(Thread.java:840)
Caused by: java.lang.ClassNotFoundException: org.eclipse.jgit.internal.JGitText
	... 2 more
Error: The process '/Users/runner/hostedtoolcache/maven/3.9.6/x64/bin/mvn' failed with exit code 1

Other information

example: https://github.com/eclipse-platform/eclipse.platform.ui/actions/runs/7529302359/job/20493249204?pr=1505)

[jukzi]

jgit/org.eclipse.jgit/src/org/eclipse/jgit/internal/util/ShutdownHook.java

Line 85 in 32e33f0

LOG.error(JGitText.get().shutdownCleanupFailed, e);

[Bananeweizen]

We also see this when trying to upgrade a Tycho 3 build to Tycho 4. Tycho uses JGit in the tycho-buildtimestamp-jgit provider (but I'm not certain whether the failure is that related to that specific usage).

Regarding the bug as such: I'd suggest to hardcode the cleanup failed message here (or to have a try-catch around the localized logging, falling back to hardcoded logging on any exception). Since the VM is shutting down, the JGitText class may or may not be loaded anymore, and that might even depend on the current JVM version or implementation.

[jukzi]

@msohn can you fix, please?

[msohn]

pushed fix for review https://eclipse.gerrithub.io/c/eclipse-jgit/jgit/+/1176056

[msohn]

Fix was merged as e6d83d6

[LorenzoBettini]

We also see this when trying to upgrade a Tycho 3 build to Tycho 4 in Xtext.
It does not make the build fail but GitHub Actions summaries show failures, though the overall jobs succeed.

@msohn the fix was merged but can we consume the fixed version somehow?

[msohn]

I tagged the 6.9.0.202403050737-r release and contributed it to the simrel build yesterday.
It's already available on repo.eclipse.org. Will deploy it to Maven central soon.

[TheSnoozer]

Hello,
thanks for the jgit-project (using it for ages now) could you perhaps let us know when you had the chance to also release the 6.9.0.202403050737-r to maven central? Thanks!

Edit: Thanks I see it released now: https://mvnrepository.com/artifact/org.eclipse.jgit/org.eclipse.jgit/6.9.0.202403050737-r

[msohn]

Yes, technically it's already deployed on Maven Central. We announce the release with Eclipse simultaneous release next Wednesday.

[henryju]

Hi, after updating to JGit 6.9 to fix the mentioned error, we are now getting:

java.lang.NoClassDefFoundError: ch/qos/logback/classic/spi/ThrowableProxy
[09:58:34.514]     	at ch.qos.logback.classic.spi.LoggingEvent.<init>(LoggingEvent.java:143)
[09:58:34.514]     	at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:424)
[09:58:34.514]     	at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:386)
[09:58:34.514]     	at ch.qos.logback.classic.Logger.error(Logger.java:543)
[09:58:34.514]     	at org.eclipse.jgit.internal.util.ShutdownHook.cleanup(ShutdownHook.java:87)
[09:58:34.514]     	at java.base/java.lang.Thread.run(Thread.java:840)
[09:58:34.514]     Caused by: java.lang.ClassNotFoundException: ch.qos.logback.classic.spi.ThrowableProxy

is it related?

[msohn]

JGit uses slf4j API for logging, if you want to use logback as logging backend you need to ensure that its jars are on the classpath

[henryju]

They are. Everything is working well until the JVM is shutting down. Isn't it the same analysis as the JGitText not found?

Since the VM is shutting down, the JGitText ThrowableProxy class may or may not be loaded anymore, and that might even depend on the current JVM version or implementation.

[henryju]

In our case, we are using JGit in an application that is using classloader isolation. So I guess the problem is that we are closing our classloader before the JGit ShutdownHook is executed.
Relying on a shutdown hook is not good for any scenario involving loading JGit in a child classloader. Would it be possible to make this behavior optional and let people manually call the cleanup method before closing their classloaders?

For the record, here is a similar discussion: classgraph/classgraph#376

[henryju]

Hi folks, would you be open for a change letting clients call the cleanup method themself instead of relying on a shutdown hook?