Prevent the REPL from warning about restricted java.lang.System
API on JDK 24
#3767
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes scala/scala3#22756
What even happens here?
JLine uses some restricted JDK API, which becomes a warning on JDK 24.
https://docs.oracle.com/en/java/javase/24/core/restricted-methods.html
Why can't we use the approach suggested in the warning?
The API being called can be enabled with
--enable-native-access
, but it is unfortunately only possible via module name.Which means the call needs to happen in a named module, on the module path.
The REPL uses a class path, not a module path. The warning suggests
ALL-UNNAMED
, as everything on the classpath doesn't have a named module and thus is just thrown into the catch-all unnamed bin.--enable-native-access=ALL-UNNAMED
is way too broad, as it could cause users to miss legitimate warnings from their code.So what do we do instead?
What I do is force JLine on the module path as well as the class path (sigh), let the JVM pick up its default module names from the JAR manifests and then enable the restricted access APIs for those paths only.
Can this break with a future JLine version bump?
Sure it can.
This is fragile, as we can't really rely on this stuff being unchanged in different JLine versions.
You might notice that the named module defaults in manifests of JLine versions used by Scala 2.13 and Scala 3 REPL differ.
I added a test, so that we have a sanity check.
The test is a bit hacky too, but what can you do.
Hacky problems require hacky solutions.
Behaviour examples
Before
After
Extra context
The remaining warning is tied to scala/scala3#9013 and will be addressed in Scala 3.8 (along with the JDK bump to 17)
cc @sjrd @lrytz