Skip to content
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

Support JEP-261 Module System #529

Open
4 tasks
retronym opened this issue Jul 5, 2018 · 10 comments
Open
4 tasks

Support JEP-261 Module System #529

retronym opened this issue Jul 5, 2018 · 10 comments
Labels
Milestone

Comments

@retronym
Copy link
Member

retronym commented Jul 5, 2018

(Part of the epic, #139)

  • Expose new command line options to scalac (and later to the scala script runner) (--module-path, etc)
  • Build atop StandardJavaFileManager and java.lang.module._, to process these options and create a ClassPath implementation and resolved module graph
  • Update Context.isAccessible to check for reads/exports edges between the call site and referenced symbol.
  • To support mixed compilation, add a parser for 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

% qscalac  -nobootcp -modulepath ""  $(f "class C { def foo = javax.xml.bind.DatatypeConverter.printBase64Binary _ }")
/tmp/a.scala:1: error: object DatatypeConverter is not a member of package javax.xml.bind
class C { def foo = javax.xml.bind.DatatypeConverter.printBase64Binary _ }
                                   ^
one error found

% qscalac  -nobootcp -modulepath "" -addmodules:java.xml.bind  $(f "class C { def foo = javax.xml.bind.DatatypeConverter.printBase64Binary _ }")

% qscalac  -nobootcp -modulepath "" $(f "class C { sun.reflect.misc.ConstructorUtil.getConstructors(null) }")
/tmp/a.scala:1: error: class ConstructorUtil in package misc cannot be accessed in package sun.reflect.misc
class C { sun.reflect.misc.ConstructorUtil.getConstructors(null) }
                           ^
one error found

% qscalac  -nobootcp -modulepath "" -addexports:java.base/sun.reflect.misc=ALL-UNNAMED  $(f "class C { sun.reflect.misc.ConstructorUtil.getConstructors(null) }")

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 with scala-asm.

@retronym retronym self-assigned this Jul 5, 2018
@retronym retronym added this to the 2.13 milestone Jul 5, 2018
@Knut-Fjellheim
Copy link

Is there a target date, or target version, for this feature?

@retronym
Copy link
Member Author

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.

@retronym
Copy link
Member Author

This test in my WIP branch shows what I've got working so far.

@adriaanm adriaanm self-assigned this Aug 22, 2018
@xuwei-k

This comment was marked as outdated.

@adriaanm

This comment was marked as outdated.

@rgoldberg
Copy link

Are there any updates for this issue? Thanks.

@som-snytt
Copy link

JDK 16 is stricter, like the sign that says last exit before toll as you head toward the bridge.

@pelamfi
Copy link

pelamfi commented Jul 4, 2023

Any news on this?

@SethTisue
Copy link
Member

SethTisue commented Jul 6, 2023

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.)

@sgammon
Copy link

sgammon commented Apr 14, 2024

Hello from 2024. It has been 6 years, 6 months, and 23 days since Java 9's release.

szeiger added a commit to szeiger/scala that referenced this issue Jul 4, 2024
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).
szeiger added a commit to szeiger/scala that referenced this issue Jul 10, 2024
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).
szeiger added a commit to databricks/scala that referenced this issue Jul 10, 2024
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).
szeiger added a commit to databricks/scala that referenced this issue Jul 10, 2024
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).
szeiger added a commit to databricks/scala that referenced this issue Jul 11, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests