JANSI: NoSuchMethodError in 4.0.10 (not present in 4.0.9)

[pmonks]

JANSI 4.0.10 appears to have a breaking regression in its initialisation logic - it's throwing a NoSuchMethodError exception; for example when calling org.jline.jansi.AnsiConsole.getTerminalWidth():

java.lang.NoSuchMethodError: 'org.jline.terminal.TerminalBuilder org.jline.terminal.TerminalBuilder.providers(java.lang.String)'
 at org.jline.jansi.AnsiConsole.doInstall (AnsiConsole.java:199)
 at org.jline.jansi.AnsiConsole.out (AnsiConsole.java:339)
 at org.jline.jansi.AnsiConsole.getTerminalWidth (AnsiConsole.java:152)
 at [user code elided]

This exact same code works on 4.0.9 and earlier.

[gnodet]

Claude Code on behalf of Guillaume Nodet

This is most likely caused by a classpath conflict rather than a regression in JLine itself.

The org.jline:jansi bundle jar is self-contained — it recompiles and includes both AnsiConsole and TerminalBuilder from source, so using it alone should never produce a NoSuchMethodError. The error occurs when another jar on the classpath also contains TerminalBuilder (e.g., an older org.jline:jline-terminal pulled in transitively by another dependency) and the class loader loads that version instead of the one bundled in the jansi jar.

To diagnose, check your dependency tree for duplicate JLine classes:

# Maven
mvn dependency:tree -Dincludes=org.jline

# Gradle
gradle dependencies --configuration runtimeClasspath | grep jline

You'll likely find a separate jline-terminal (or jline bundle) at a different version. The fix is to exclude the conflicting transitive dependency or align all JLine artifacts to the same version.

That said, #1767 adds a defensive guard so that TerminalBuilder.providers() is only called when the jansi.providers system property is actually set. Since passing null was a no-op anyway, this makes AnsiConsole more resilient to version mismatches at no cost.

[pmonks]

Ah yes I see org.fusesource.jansi/jansi@1.16 coming in transitively via other implicit dependencies. I wonder if addressing fusesource/jansi#315 would help tooling to identify this? The change to jansi's groupId between v2 and v3 means that tooling can't follow this artifact forward and detect version conflicts, and adding relocation metadata might help with that (though I'm not 100% sure - it may vary by build tool).

[gnodet]

Claude Code on behalf of Guillaume Nodet

The org.fusesource.jansi:jansi:1.16 on your classpath is likely a red herring here — it uses the org.fusesource.jansi package, which is completely separate from org.jline.*. It doesn't contain org.jline.terminal.TerminalBuilder and can't cause the NoSuchMethodError.

The issue is purely within JLine artifacts: you likely have two jars both containing org.jline.terminal.TerminalBuilder — the org.jline:jansi bundle (which recompiles and bundles it) and a separate org.jline:jline-terminal (or org.jline:jline) at an older version pulled transitively by another dependency. The class loader picks the older one, which doesn't have the providers() method.

A relocation from org.fusesource.jansi:jansi → org.jline:jansi wouldn't help with this — the conflict is between different org.jline artifacts. To fix it, check for the duplicate:

mvn dependency:tree -Dincludes=org.jline

Then either exclude the older org.jline:jline-terminal / org.jline:jline or align all JLine artifacts to the same version.

[pmonks]

Hmmm I wouldn't have expected the presence of JLine on the classpath to have any effect on Jansi. Isn't the dependency direction the other way around (JLine depends on Jansi)?