Changing a library dependency, which internally holds native code, might have potential to break a bunch of things downstream. For example console loads Scala REPL, which likely also uses similar JLine + JAnsi combo. We might try this out first on sbt 2.x side first?

Indeed good to be careful. Btw other than console (Scala 2.12, Scala 2.13, Scala 3), what are things to look for?

I think the main diamond problem we should watch out for is console. If I recall correctly sbt takes over the classloading of JLine (and JAnsi too maybe?), so if it works with a few on the operating system, it should be ok for most.

Another angle we might need to watch out for is sbtn building.

This PR should be safe in terms of diamond dependency issue, since

• None of scala2, scala3 relies on jansi-core
• None of scala2, scala3 relies on org.fusesource.jansi
• None of scala2, scala3 relies on jline-terminal-jansi
• org.fusesource.jansi still exists in sbt classpath though https://github.com/sbt/jline2, so downstream & sbt's classloader would still have org.fusesource.jansi in their classpath. (So even if some downstream relies on org.fusesource.jansi, it is still available).

Furthermore jansi-core contains no native code (as can be seen in https://github.com/jline/jline3/tree/8852b39c788f8d3d9158aeb3aa8d067153a4eaae/jansi-core), paired with the fact that org.fusesource.jansi still exists in classpath, indicates that there's likely no native code specific issue.

However I definitely understand the concern (considering that we released broken Linux sbtn not so long ago). Since this PR is non-essential (as #7865 can be fixed alternatively via sbt/jline2#6), we can make this PR target 2.x if the risk is deemed too high.

Tested sbt console on a Scala 2.12.20 project, a Scala 2.13.15 project and a Scala 3.3.4 project on Windows. On all 3 projects, console works properly.

Shall then test sbtn console on Windows/Mac and then sbt console on Mac.

If jansi doesn't have native code, then hopefully it won't break sbtn building. I think the next step would be to publish a new version of https://github.com/sbt/jline2.

I made a commit to test sbtn build here: Friendseeker/sbtn-dist@91efb1f

The build succeeded. I am currently testing whether sbtn console actually works using the built sbtn.

If jansi doesn't have native code, then hopefully it won't break sbtn building. I think the next step would be to publish a new version of https://github.com/sbt/jline2.

Your concern about sbtn is spot on. Friendseeker/sbtn-dist@91efb1f succeeded but the resulting windows sbtn build is nonfunctional:

PS D:\Repos\21315> & 'C:\Users\Jerry Tan\AppData\Local\Coursier\cache\arc\https\github.com\sbt\sbt\releases\download\v1.10.4\sbt-1.10.4.zip\sbt\bin\sbtn-new.exe'
Nov 07, 2024 6:02:17 PM org.jline.utils.Log logr
WARNING: Unable to create a system terminal, creating a dumb terminal (enable debug logging for more information)
[info] entering *experimental* thin client - BEEP WHIRR
[info] terminate the server with `shutdown`
[info] disconnect from the server with `exit`

(The sbt shell freezes and does not respond to any input).

The issue is probably with usage of org.jline.jansi-core instead of org.jline.jansi. I am making the switch right now and shall retest the cartesian product of [Scala 2.12 project, Scala 2.13 project, Scala 3.3.4 project], [Windows, Mac], [sbt console, sbtn console].

But yeah I see how native image demonstrates Murphy's Law now... I shall keep this PR up here merely for testing purpose. Once all tests passes we shall cherry pick the PR commits to target develop branch and close this PR.