Chore: Update terminal dependencies

[electronicboy]

Need to also look into log4j, but, so far

1. Updated to jline-terminal 3.26.1 - jline, however, has deprecated their jansi provider, and so, we're going back to JNA. FFM looks interesting, but, might not work on java 21, and, seems to requore some additional java flags to open stuff up to allow it to work, however, seemed to work without on macOS?

2. added a hackaround to try to migate the terminal issues we're facing on windows, will probably look towards adding a detection step for PS7 so we can disable the hack, but, in the meantime, this at least works around the issue.

(Closes #10674) (Closes #10405) Cross ref: https://github.com/jline/jline3/issues/952

---

Download the paperclip jar for this pull request: paper-10675.zip

[derklaro]

Updated to jline-terminal 3.26.1 - jline, however, has deprecated their jansi provider, and so, we're going back to JNA. FFM looks interesting, but, might not work on java 21, and, seems to requore some additional java flags to open stuff up to allow it to work, however, seemed to work without on macOS?

It might still look like it works, but it won't use the FFM terminal implementation. While there is no restriction from the JVM side to enable native access yet (see JEP 472 for first steps into that direction), JLine added a check to ensure that native access is enabled (which implicitly falls back to the another provider if it's not):

https://github.com/jline/jline3/blob/9489e1b15bd1ee9dd87393aeec7fc5489fbc8a09/terminal-ffm/src/main/java/org/jline/terminal/impl/ffm/FfmTerminalProvider.java#L34-L39

[electronicboy]

Yea, I guess I didn't notice it didn't enable, because *nix is pretty much in an "it just works", it's only really Windows which bites us in the ass here.

I think that in the long term, it will probably be a case of "if you want anything bar a basic terminal on Windows, run with this flag" type of deal, I don't care for the time sink that has been proper terminal support for windows anymore, at least the changes here should give us a situation which isn't entirely broken for now.

I don't have hardware that is running Windows, and spinning up VM instances to toy around with a platform that doesn't even hold 15% of the market share seems like an entire waste of time considering it's the platform that gives us the most hassle here.

[MiniDigger]

putting my findings here. tested on windows 11 with windows terminal running cmd with corretto 22 and 23.

• jline-terminal-jansi:3.21.0 (master) is missing keystrokes.
• exclude("org.fusesource.jansi", "jansi") disables advanced features (but fixed keystrokes)
• jline-terminal-jansi:3.27.1 is missing keystrokes
• jline-terminal-jni:3.27.1 is missing keystrokes
• jline-terminal-ffm:3.27.1 doesn't have advanced features (unless you add --enable-native-access=ALL-UNNAMED, which fixes keystrokes, that flag can also be added to the manifest!)
• jansi and jni with -Djdk.console=java.base fixes keystrokes
• jline-terminal-ffm:3.27.1 on 21 disables advanced features

I think ffm is the way forward. its available starting java 22 and the manifest entry allows us to get around java cracking down on undocumented native access. jline readme mentions that the providers are checked in ffm > jni order, so we should be able to just ship both and it will fallback to jni on java 21, but sadly that doesnt seem to work for me, it seems to pick jni on 22 for me?

[electronicboy]

Superceeded by https://github.com/PaperMC/Paper/pull/11631