-
Notifications
You must be signed in to change notification settings - Fork 14
Support JEP-261 Module System #529
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Is there a target date, or target version, for this feature? |
I hope its ready for Scala 2.13.0 later this year. If not, then we'll make sure we at least have the plumbing installed to add it for 2.13.1. |
This test in my WIP branch shows what I've got working so far. |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
Are there any updates for this issue? Thanks. |
JDK 16 is stricter, like the sign that says last exit before toll as you head toward the bridge. |
Any news on this? |
Nobody is currently working on this (to my knowledge, but I'm pretty sure). It's unlikely to progress without an external contributor or sponsor. Any planning around this would need to include Scala 3, since as a rule as we don't add new features to Scala 2 unless the path is clear for adding the feature to Scala 3 as well. (Targeting only Scala 3 would be acceptable.) |
Hello from 2024. It has been 6 years, 6 months, and 23 days since Java 9's release. |
This PR adds a new `-system` / `--system` setting to scalac which mimics its counterpart in javac. This fixes the biggest problem (at least for us) of scala/bug#13015. It is now possible to compile code against an older system image without enforcing strict module access. scalac generally does not enforce modules (scala/scala-dev#529) but it does when using `-release` (with class lookup based on `ct.sym`) and there was no way to opt out of these restrictions. The usual opt-out in javac is `--add-exports` but it is not supported for system modules in combination with `--release` (https://bugs.openjdk.org/browse/JDK-8178152) so there is no expectation that scalac could support it. Instead the solution for javac is to replace `--release` with a combination of `-source`, `-target` and a system image for the target version via `--system`. This combination, unlike `--release`, can be used with `--add-exports`. If scalac adds full module support at a later time (with access restrictions enabled by default) it will also need to support `--add-exports` and allow its use in combination with `--system`. I am also un-deprecating `-target` (which was deprecated in favor of `-release`) because it now has a legitimate use in combination with an alternative system image (just like in javac where it is serves the same purpose and is not deprecated, either).
This PR adds a new `-system` / `--system` setting to scalac which mimics its counterpart in javac. This fixes the biggest problem (at least for us) of scala/bug#13015. It is now possible to compile code against an older system image without enforcing strict module access. scalac generally does not enforce modules (scala/scala-dev#529) but it does when using `-release` (with class lookup based on `ct.sym`) and there was no way to opt out of these restrictions. The usual opt-out in javac is `--add-exports` but it is not supported for system modules in combination with `--release` (https://bugs.openjdk.org/browse/JDK-8178152) so there is no expectation that scalac could support it. Instead the solution for javac is to replace `--release` with a combination of `-source`, `-target` and a system image for the target version via `--system`. This combination, unlike `--release`, can be used with `--add-exports`. If scalac adds full module support at a later time (with access restrictions enabled by default) it will also need to support `--add-exports` and allow its use in combination with `--system`. I am also un-deprecating `-target` (which was deprecated in favor of `-release`) because it now has a legitimate use in combination with an alternative system image (just like in javac where it serves the same purpose and is not deprecated, either).
This PR adds a new `-system` / `--system` setting to scalac which mimics its counterpart in javac. This fixes the biggest problem (at least for us) of scala/bug#13015. It is now possible to compile code against an older system image without enforcing strict module access. scalac generally does not enforce modules (scala/scala-dev#529) but it does when using `-release` (with class lookup based on `ct.sym`) and there was no way to opt out of these restrictions. The usual opt-out in javac is `--add-exports` but it is not supported for system modules in combination with `--release` (https://bugs.openjdk.org/browse/JDK-8178152) so there is no expectation that scalac could support it. Instead the solution for javac is to replace `--release` with a combination of `-source`, `-target` and a system image for the target version via `--system`. This combination, unlike `--release`, can be used with `--add-exports`. If scalac adds full module support at a later time (with access restrictions enabled by default) it will also need to support `--add-exports` and allow its use in combination with `--system`. I am also un-deprecating `-target` (which was deprecated in favor of `-release`) because it now has a legitimate use in combination with an alternative system image (just like in javac where it is serves the same purpose and is not deprecated, either).
This PR adds a new `-system` / `--system` setting to scalac which mimics its counterpart in javac. This fixes the biggest problem (at least for us) of scala/bug#13015. It is now possible to compile code against an older system image without enforcing strict module access. scalac generally does not enforce modules (scala/scala-dev#529) but it does when using `-release` (with class lookup based on `ct.sym`) and there was no way to opt out of these restrictions. The usual opt-out in javac is `--add-exports` but it is not supported for system modules in combination with `--release` (https://bugs.openjdk.org/browse/JDK-8178152) so there is no expectation that scalac could support it. Instead the solution for javac is to replace `--release` with a combination of `-source`, `-target` and a system image for the target version via `--system`. This combination, unlike `--release`, can be used with `--add-exports`. If scalac adds full module support at a later time (with access restrictions enabled by default) it will also need to support `--add-exports` and allow its use in combination with `--system`. I am also un-deprecating `-target` (which was deprecated in favor of `-release`) because it now has a legitimate use in combination with an alternative system image (just like in javac where it is serves the same purpose and is not deprecated, either).
This PR adds a new `-system` / `--system` setting to scalac which mimics its counterpart in javac. This fixes the biggest problem (at least for us) of scala/bug#13015. It is now possible to compile code against an older system image without enforcing strict module access. scalac generally does not enforce modules (scala/scala-dev#529) but it does when using `-release` (with class lookup based on `ct.sym`) and there was no way to opt out of these restrictions. The usual opt-out in javac is `--add-exports` but it is not supported for system modules in combination with `--release` (https://bugs.openjdk.org/browse/JDK-8178152) so there is no expectation that scalac could support it. Instead the solution for javac is to replace `--release` with a combination of `-source`, `-target` and a system image for the target version via `--system`. This combination, unlike `--release`, can be used with `--add-exports`. If scalac adds full module support at a later time (with access restrictions enabled by default) it will also need to support `--add-exports` and allow its use in combination with `--system`. I am also un-deprecating `-target` (which was deprecated in favor of `-release`) because it now has a legitimate use in combination with an alternative system image (just like in javac where it serves the same purpose and is not deprecated, either). # Conflicts: # src/compiler/scala/tools/nsc/Global.scala # src/compiler/scala/tools/nsc/classpath/DirectoryClassPath.scala # src/compiler/scala/tools/nsc/settings/StandardScalaSettings.scala
(Part of the epic, #139)
scalac
(and later to thescala
script runner) (--module-path
, etc)StandardJavaFileManager
andjava.lang.module._
, to process these options and create aClassPath
implementation and resolved module graphContext.isAccessible
to check for reads/exports edges between the call site and referenced symbol.module-info.java
, and feed a descriptor of the module descriptor to the module graph configuration.WIP: https://github.com/retronym/scala/tree/topic/jpms
Non Goals
Support for
--module-source-path
. A batch of source files will be associated with at most one module.Open Issues
How should we structure our build to allow us to call Java 9 APIs from this code path? I'm thinking we do this from a small pure-Java project and incorporate the results into
scala-reflect.jar
, similar to how we've dealt withscala-asm
.The text was updated successfully, but these errors were encountered: