Use jline bundle built against Java 8 #10889
Conversation
|
I haven't looked yet, but the comment at the end of that ticket says jline just fields the I wonder if jline should be a multi-release jar. Is a tool justified in assuming it can load a class file that is not versioned? The service loader shouldn't even see the class. |
|
@som-snytt thanks for surfacing scala/bug#12994 — I'd forgotten about it the JLine ticket with the most informative discussion is jline/jline3#937 @sideeffffect what symptoms are you seeing that show the need for this, what are the "unnecessary issues" you refer to? this is only the second complaint we've received, even though Scala 2.13.14 came out six months ago. what is your "pipeline" doing that is even noticing this? also, before merging this, I'd want to know what is the potential impact of excluding FFM support. might that make the REPL work less well for some users? |
AFAIK we're not using any of this newly introduced functionality. We should be safe to switch to the jdk8 variant 🤞 |
|
thank you! I did not know this existed |
…27.1 (was 3.27.0) (#22205) as per the https://github.com/jline/jline3 readme and as per discussion and linked items on #22201 fixes #22201 note that as far as I can tell, the stuff I removed from libexec/common-shared is dead code @philwalk dunno if you're still around but judging from #12405 you might be a good reviewer here note that I believe we _don't_ need to also port scala/scala#10889 here, since we are already using separate JLine JARs rather than the all-in-one JAR I've chosen not to upgrade all the way to JLine 3.28.0 at the moment, as it is quite new (2 days ago) and doesn't appear to have any fixes that might be critical.
The default jline bundle contains classes built against Java 22, which is causing unnecessary issues.
related: