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 features of JDK 9+ #139

Open
retronym opened this Issue Apr 25, 2016 · 49 comments

Comments

Projects
None yet
@retronym
Member

retronym commented Apr 25, 2016

For the current support status of each JDK version, see https://docs.scala-lang.org/overviews/jdk-compatibility/overview.html

JDK9 JEP list

@retronym

This comment has been minimized.

Show comment
Hide comment
@retronym

retronym Apr 25, 2016

Member

To whet the collective appetite, here's my branch that adapts to JEP 220 up and running:

⚡ qscala
Welcome to Scala 2.12.0-20160425-151134-5e07d57 (Java HotSpot(TM) 64-Bit Server VM, Java 9-ea).
Type in expressions for evaluation. Or try :help.

scala> java.util.List.of(1, 2, 3)
res0: java.util.List[Int] = [1, 2, 3]
Member

retronym commented Apr 25, 2016

To whet the collective appetite, here's my branch that adapts to JEP 220 up and running:

⚡ qscala
Welcome to Scala 2.12.0-20160425-151134-5e07d57 (Java HotSpot(TM) 64-Bit Server VM, Java 9-ea).
Type in expressions for evaluation. Or try :help.

scala> java.util.List.of(1, 2, 3)
res0: java.util.List[Int] = [1, 2, 3]

@retronym retronym added this to the 2.12.1+ milestone Apr 27, 2016

@retronym retronym self-assigned this Apr 27, 2016

@retronym retronym referenced this issue Jul 19, 2016

Merged

Varming/5.1 #11

@varming

This comment has been minimized.

Show comment
Hide comment
@varming

varming Jul 20, 2016

With less than nine months to the release of JDK9 not being able to run Scala programs on the early access releases is a serious concern, so it is great to see that work has started.

varming commented Jul 20, 2016

With less than nine months to the release of JDK9 not being able to run Scala programs on the early access releases is a serious concern, so it is great to see that work has started.

@SethTisue

This comment has been minimized.

Show comment
Hide comment
@SethTisue

SethTisue Dec 8, 2016

Member

@retronym did 2.12.1 check some more of these boxes?

Member

SethTisue commented Dec 8, 2016

@retronym did 2.12.1 check some more of these boxes?

@retronym

This comment has been minimized.

Show comment
Hide comment
@retronym

retronym Feb 5, 2017

Member

I have submitted a PR to SBT to start the ball rolling for Java 9 support. Because SBT internally uses an old version of scalac to compile build definitions, I decided to create a tool to export a jrt:/modules/*/** to rt.jar to bridge JDK9 to the older compiler.

This approach also enables your project to be compiled with, say, Scala 2.11.8, which might help some more folks test out JDK9, without first needing to upgrade to the 2.12 series.

Warning: we are yet to implement the additional access checks required by JEP-261. Until then, you can get LinkageError-s at runtime for code that passes the Scala type checker. So while I encourage testing and experimentation, use this at your own risk in production.

Member

retronym commented Feb 5, 2017

I have submitted a PR to SBT to start the ball rolling for Java 9 support. Because SBT internally uses an old version of scalac to compile build definitions, I decided to create a tool to export a jrt:/modules/*/** to rt.jar to bridge JDK9 to the older compiler.

This approach also enables your project to be compiled with, say, Scala 2.11.8, which might help some more folks test out JDK9, without first needing to upgrade to the 2.12 series.

Warning: we are yet to implement the additional access checks required by JEP-261. Until then, you can get LinkageError-s at runtime for code that passes the Scala type checker. So while I encourage testing and experimentation, use this at your own risk in production.

@retronym

This comment has been minimized.

Show comment
Hide comment
@retronym

retronym May 2, 2017

Member

Discussion on the Java Language Spec changes related to modules, thread started by Eclipse JDT seeking to implement the spec. http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012433.html

Member

retronym commented May 2, 2017

Discussion on the Java Language Spec changes related to modules, thread started by Eclipse JDT seeking to implement the spec. http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012433.html

@ijuma

This comment has been minimized.

Show comment
Hide comment
@ijuma

ijuma Jul 19, 2017

Another Java 9 issue: scala/bug#10418

ijuma commented Jul 19, 2017

Another Java 9 issue: scala/bug#10418

@SethTisue

This comment has been minimized.

Show comment
Hide comment
@SethTisue
Member

SethTisue commented Jul 19, 2017

@ijuma

This comment has been minimized.

Show comment
Hide comment
@ijuma

ijuma Aug 10, 2017

JEP 247: Compile for Older Platform Versions is also relevant. It would be nice if scalac could understand $JDK_ROOT/lib/ct.sym so that a newer JDK could be safely used to build for an older version.

ijuma commented Aug 10, 2017

JEP 247: Compile for Older Platform Versions is also relevant. It would be nice if scalac could understand $JDK_ROOT/lib/ct.sym so that a newer JDK could be safely used to build for an older version.

@asarkar

This comment has been minimized.

Show comment
Hide comment
@asarkar

asarkar Aug 28, 2017

Is there a target release for addressing all the issues listed here, and reported by the users, or is it going to be on best-efforts basis?

asarkar commented Aug 28, 2017

Is there a target release for addressing all the issues listed here, and reported by the users, or is it going to be on best-efforts basis?

@retronym

This comment has been minimized.

Show comment
Hide comment
@retronym

retronym Aug 28, 2017

Member

@asarkar My primary goal at the moment is removing impediments to building and running Scala 2.12 on JDK9. We have been able to build and test the Play Framework, and the Akka team is working through similar testing at the moment.

I then want to implement support in the Scala typechecker for JPMS. I expect this will be done in Q4 this year. I'm hopeful that we could ship this in either a minor release of Scala 2.12, or as an experimental compiler plugin for Scala 2.12. It will introduce a dependency on the Java 9 standard library, which will complicate our build somewhat, as in general the compiler should only require Java 8.

I don't have a timeframe for the full list, but I'm keen to hear about what parts are most important for our users to help prioritize.

Member

retronym commented Aug 28, 2017

@asarkar My primary goal at the moment is removing impediments to building and running Scala 2.12 on JDK9. We have been able to build and test the Play Framework, and the Akka team is working through similar testing at the moment.

I then want to implement support in the Scala typechecker for JPMS. I expect this will be done in Q4 this year. I'm hopeful that we could ship this in either a minor release of Scala 2.12, or as an experimental compiler plugin for Scala 2.12. It will introduce a dependency on the Java 9 standard library, which will complicate our build somewhat, as in general the compiler should only require Java 8.

I don't have a timeframe for the full list, but I'm keen to hear about what parts are most important for our users to help prioritize.

@smarter

This comment has been minimized.

Show comment
Hide comment
@smarter

smarter Sep 19, 2017

Update Zinc to understand that jrt:// classpath entries should have a timestamp based on the JDK (maybe $JAVA_HOME/jmods/*.mod? Find out exactly what file backs jrt://)

Surely that's not right for modules on the modulepath that are not part of the JDK?

smarter commented Sep 19, 2017

Update Zinc to understand that jrt:// classpath entries should have a timestamp based on the JDK (maybe $JAVA_HOME/jmods/*.mod? Find out exactly what file backs jrt://)

Surely that's not right for modules on the modulepath that are not part of the JDK?

@retronym

This comment has been minimized.

Show comment
Hide comment
@retronym

retronym Sep 19, 2017

Member

Once we have a --modulepath compiler option, we'll be able to access the contents are regular JARs (well, apart from the .jmod format). So we might not actually access them via the jrt:// filesystem at all.

Member

retronym commented Sep 19, 2017

Once we have a --modulepath compiler option, we'll be able to access the contents are regular JARs (well, apart from the .jmod format). So we might not actually access them via the jrt:// filesystem at all.

@lukaseder

This comment has been minimized.

Show comment
Hide comment
@lukaseder

lukaseder Oct 20, 2017

I managed to compile stuff on the JDK 9 using Scala 2.12.3, but not using 2.11.11 where I'm getting this error:

error: scala.reflect.internal.MissingRequirementError: object java.lang.Object in compiler mirror not found.

Is JDK 9 usage not supported with 2.11, or might there be a bug worth reporting?

lukaseder commented Oct 20, 2017

I managed to compile stuff on the JDK 9 using Scala 2.12.3, but not using 2.11.11 where I'm getting this error:

error: scala.reflect.internal.MissingRequirementError: object java.lang.Object in compiler mirror not found.

Is JDK 9 usage not supported with 2.11, or might there be a bug worth reporting?

@lrytz

This comment has been minimized.

Show comment
Hide comment
@lrytz

lrytz Oct 20, 2017

Member

This is probably #304, fixed for 2.12 in scala/scala#6097. We're backporting some fixes for a 2.11.12 release, should be out soon.

Member

lrytz commented Oct 20, 2017

This is probably #304, fixed for 2.12 in scala/scala#6097. We're backporting some fixes for a 2.11.12 release, should be out soon.

@lukaseder

This comment has been minimized.

Show comment
Hide comment
@lukaseder

lukaseder Oct 20, 2017

Cook, thanks very much for the pointer, @lrytz !

lukaseder commented Oct 20, 2017

Cook, thanks very much for the pointer, @lrytz !

@mkurz

This comment has been minimized.

Show comment
Hide comment
@mkurz

mkurz Oct 25, 2017

I opened pull request scala/scala#6146 to add support for -target:jvm-1.9.

mkurz commented Oct 25, 2017

I opened pull request scala/scala#6146 to add support for -target:jvm-1.9.

@clhodapp

This comment has been minimized.

Show comment
Hide comment
@clhodapp

clhodapp Oct 26, 2017

It would be great if Scala Team could publish an official position on the readiness of Scala for JDK/JRE9 (even if it's just a line or two integrated into the download directions on scala-lang.org). As it stands, it's not clear at all to most developers whether it's considered safe to use Scala with Java 9. This is, of course, completely separate from fully leveraging Java 9, which is obviously going to be a substantial ongoing effort for quite a while (as reflected here).

clhodapp commented Oct 26, 2017

It would be great if Scala Team could publish an official position on the readiness of Scala for JDK/JRE9 (even if it's just a line or two integrated into the download directions on scala-lang.org). As it stands, it's not clear at all to most developers whether it's considered safe to use Scala with Java 9. This is, of course, completely separate from fully leveraging Java 9, which is obviously going to be a substantial ongoing effort for quite a while (as reflected here).

@SethTisue

This comment has been minimized.

Show comment
Hide comment
@SethTisue

SethTisue Oct 26, 2017

Member

re: download directions on scala-lang.org, see scala/scala-lang#761

Member

SethTisue commented Oct 26, 2017

re: download directions on scala-lang.org, see scala/scala-lang#761

@markehammons

This comment has been minimized.

Show comment
Hide comment
@markehammons

markehammons Oct 26, 2017

I would like to say

javac allows programmers to declare module requirements, exports inline in the sourcetree ("module-info.java" files). What should we do?

is of great importance to me. While I've been running my scala code on java 9 recently (and also openJ9), I haven't bothered messing with modules yet because scala doesn't support them. This is a shame imo, cause while stuff like private[package] is nice, I'd really love to have jpms modules instead.

markehammons commented Oct 26, 2017

I would like to say

javac allows programmers to declare module requirements, exports inline in the sourcetree ("module-info.java" files). What should we do?

is of great importance to me. While I've been running my scala code on java 9 recently (and also openJ9), I haven't bothered messing with modules yet because scala doesn't support them. This is a shame imo, cause while stuff like private[package] is nice, I'd really love to have jpms modules instead.

@retronym

This comment has been minimized.

Show comment
Hide comment
@retronym

retronym Nov 1, 2017

Member

@markehammons The plan is that you will define your module in the same way as you would in Java by adding a module-info.java file to your source tree. All the build tools support mixed Java/Scala projects.

The missing piece of the puzzle is getting scalac to respect these limitations.

I've just finished backporting the of Java 9 support we have so far from 2.12.4 back to the imminent 2.10.7 and 2.11.12 to help folks migrate. In particular, this is designed to help people using SBT 0.13 (which implies use of Scala 2.10.x).

Once those releases are done, I'll add support in 2.12.5 for respecting multi-release JARs and the --release compiler option (to limit compilation to, e.g. the Java 8 subset of the Java standard library). These are relatively low hanging fruit.

Next cab off the rank will be full support for JPMS modules.

@clhodapp After the backport releases I'll blog about the state of JDK 9 support and the roadmap.

Member

retronym commented Nov 1, 2017

@markehammons The plan is that you will define your module in the same way as you would in Java by adding a module-info.java file to your source tree. All the build tools support mixed Java/Scala projects.

The missing piece of the puzzle is getting scalac to respect these limitations.

I've just finished backporting the of Java 9 support we have so far from 2.12.4 back to the imminent 2.10.7 and 2.11.12 to help folks migrate. In particular, this is designed to help people using SBT 0.13 (which implies use of Scala 2.10.x).

Once those releases are done, I'll add support in 2.12.5 for respecting multi-release JARs and the --release compiler option (to limit compilation to, e.g. the Java 8 subset of the Java standard library). These are relatively low hanging fruit.

Next cab off the rank will be full support for JPMS modules.

@clhodapp After the backport releases I'll blog about the state of JDK 9 support and the roadmap.

@ijuma

This comment has been minimized.

Show comment
Hide comment
@ijuma

ijuma Nov 7, 2017

Happy to hear about --release. As you say, it's low hanging fruit and it simplifies the contributor experience (no need to ask them to install an older JDK).

ijuma commented Nov 7, 2017

Happy to hear about --release. As you say, it's low hanging fruit and it simplifies the contributor experience (no need to ask them to install an older JDK).

@schmitch

This comment has been minimized.

Show comment
Hide comment
@schmitch

schmitch Nov 10, 2017

@retronym so the way forward to use the module-system is to place a module-info.java into the scala/ folder? doesn't that seems wierd.
Can't the scala compiler have his own module-info.scala, I don't think it would be great to put *.java files in 100% scala libraries?!

schmitch commented Nov 10, 2017

@retronym so the way forward to use the module-system is to place a module-info.java into the scala/ folder? doesn't that seems wierd.
Can't the scala compiler have his own module-info.scala, I don't think it would be great to put *.java files in 100% scala libraries?!

@saosebastiao

This comment has been minimized.

Show comment
Hide comment
@saosebastiao

saosebastiao Nov 22, 2017

javac allows programmers to declare module requirements, exports inline in the sourcetree ("module-info.java" files). What should we do?

A suggestion: modify or make available several different App-like trait mixins which provide implicit values representing module capabilities. Then you statically control availability of the resulting classes and methods via implicit views or generalized type constraints. For example:

object Main extends JVM9ModuleApp with ConsoleModule

would make System.out.* available via a dependency on the relevant jdk module, and it would expose methods like println via a (implicit console: C =:= Console) type constraint. If ConsoleModule is not mixed in, the implicit resolution would fail and println would generate a compile time error.

Just as an FYI, this approach would be considered a form of a coeffect system. Coeffects are the dual of effects: where an effect tracks what a program does to the world, a coeffect tracks what is required of it. It could also be extremely extensible...if the implicit coeffect provided represents availability of a type of code generator in the compiler, it could dispatch that code to that code generator. This would allow true unification of the available backends (scala-native, scalajs, scalajvm) into a single compiler, and allow cross compiled apps as well as typesafe client-server apps within the same compilation project. It could also enable non-jvm targets to finely control code stdlib availability as well as code generation, taking into consideration the os/platform APIs that are available. Some possibilities include:

object Client extends JsApp with ES6Gen { ... }
object Server extends JVM8App with CudaGen { ... }` 

or even

object MyAndroidApp extends AndroidApp with API26 with NetworkPermissions with LocationPermissions { ... }
object MyIOSApp extends NativeApp with MulticoreRuntime with CocoaTouch { ... } 

Tomas Petricek of the F# community has done a lot of work formalizing the concept of coeffects and has created an amazing website dedicated to explaining the topic. The possibilities are enough to make me giddy. I love scala as a language, and I love the direction that the community is going with it (scalajs, scala-native, etc.), but all of that unified via a coeffect system could be transformative for cross-platform programming in the same way that Rust is transforming systems programming. And the jdk9 module system is the perfect start point for it.

saosebastiao commented Nov 22, 2017

javac allows programmers to declare module requirements, exports inline in the sourcetree ("module-info.java" files). What should we do?

A suggestion: modify or make available several different App-like trait mixins which provide implicit values representing module capabilities. Then you statically control availability of the resulting classes and methods via implicit views or generalized type constraints. For example:

object Main extends JVM9ModuleApp with ConsoleModule

would make System.out.* available via a dependency on the relevant jdk module, and it would expose methods like println via a (implicit console: C =:= Console) type constraint. If ConsoleModule is not mixed in, the implicit resolution would fail and println would generate a compile time error.

Just as an FYI, this approach would be considered a form of a coeffect system. Coeffects are the dual of effects: where an effect tracks what a program does to the world, a coeffect tracks what is required of it. It could also be extremely extensible...if the implicit coeffect provided represents availability of a type of code generator in the compiler, it could dispatch that code to that code generator. This would allow true unification of the available backends (scala-native, scalajs, scalajvm) into a single compiler, and allow cross compiled apps as well as typesafe client-server apps within the same compilation project. It could also enable non-jvm targets to finely control code stdlib availability as well as code generation, taking into consideration the os/platform APIs that are available. Some possibilities include:

object Client extends JsApp with ES6Gen { ... }
object Server extends JVM8App with CudaGen { ... }` 

or even

object MyAndroidApp extends AndroidApp with API26 with NetworkPermissions with LocationPermissions { ... }
object MyIOSApp extends NativeApp with MulticoreRuntime with CocoaTouch { ... } 

Tomas Petricek of the F# community has done a lot of work formalizing the concept of coeffects and has created an amazing website dedicated to explaining the topic. The possibilities are enough to make me giddy. I love scala as a language, and I love the direction that the community is going with it (scalajs, scala-native, etc.), but all of that unified via a coeffect system could be transformative for cross-platform programming in the same way that Rust is transforming systems programming. And the jdk9 module system is the perfect start point for it.

@devshorts

This comment has been minimized.

Show comment
Hide comment
@devshorts

devshorts Jan 18, 2018

Out of curiosity is there still activity on this? I realize this is a tricky ticket, but JDK10 is scheduled for GA in march http://openjdk.java.net/projects/jdk/10/ so it'd be nice to not be 2 major versions behind in scala land

devshorts commented Jan 18, 2018

Out of curiosity is there still activity on this? I realize this is a tricky ticket, but JDK10 is scheduled for GA in march http://openjdk.java.net/projects/jdk/10/ so it'd be nice to not be 2 major versions behind in scala land

@smarter

This comment has been minimized.

Show comment
Hide comment
@smarter

smarter Jan 19, 2018

@devshorts This ticket covers a wide range of Java 9 related things. It'd be helpful if you could indicate which ones in particular you're interested in. Note that the latest releases of sbt, Scala 2.10, 2.11 and 2.12 work correctly on Java 9 and produce code that can be run on Java 9.

smarter commented Jan 19, 2018

@devshorts This ticket covers a wide range of Java 9 related things. It'd be helpful if you could indicate which ones in particular you're interested in. Note that the latest releases of sbt, Scala 2.10, 2.11 and 2.12 work correctly on Java 9 and produce code that can be run on Java 9.

@SethTisue

This comment has been minimized.

Show comment
Hide comment
@SethTisue

SethTisue Jan 19, 2018

Member

@devshorts JDK 9 in general is still very much on the collective mind of the Scala and tooling teams at Lightbend and remains near the top of our priorities. (and thanks @smarter for noting some of the progress made in the last few months)

Member

SethTisue commented Jan 19, 2018

@devshorts JDK 9 in general is still very much on the collective mind of the Scala and tooling teams at Lightbend and remains near the top of our priorities. (and thanks @smarter for noting some of the progress made in the last few months)

@SethTisue

This comment has been minimized.

Show comment
Hide comment
@SethTisue

SethTisue Jan 19, 2018

Member

note that community participation in making progress on remaining checkboxes and helping them happen faster is very much welcome

Member

SethTisue commented Jan 19, 2018

note that community participation in making progress on remaining checkboxes and helping them happen faster is very much welcome

@smarter

This comment has been minimized.

Show comment
Hide comment
@smarter

smarter Jan 19, 2018

Ideally, we would have a documentation page "Scala on Java 9" to point people to. The current situation is very confusing since if you have an outdated sbt/scalac you just get obscure error messages.

smarter commented Jan 19, 2018

Ideally, we would have a documentation page "Scala on Java 9" to point people to. The current situation is very confusing since if you have an outdated sbt/scalac you just get obscure error messages.

@SethTisue

This comment has been minimized.

Show comment
Hide comment
@SethTisue
Member

SethTisue commented Jan 19, 2018

@SethTisue

This comment has been minimized.

Show comment
Hide comment
@SethTisue

SethTisue Jan 19, 2018

Member

Ideally, we would have a documentation page "Scala on Java 9" to point people to

totally agree. I opened scala/docs.scala-lang#1000 on it

Member

SethTisue commented Jan 19, 2018

Ideally, we would have a documentation page "Scala on Java 9" to point people to

totally agree. I opened scala/docs.scala-lang#1000 on it

@xuwei-k

This comment has been minimized.

Show comment
Hide comment
@xuwei-k

xuwei-k Feb 12, 2018

FYI. I have filed JDK10 issue scala/bug#10717

xuwei-k commented Feb 12, 2018

FYI. I have filed JDK10 issue scala/bug#10717

@apjanke apjanke referenced this issue Feb 12, 2018

Merged

scala@2.10: require Java 8 specifically #24041

4 of 4 tasks complete
@SethTisue

This comment has been minimized.

Show comment
Hide comment
@SethTisue

SethTisue Feb 21, 2018

Member

a basic page http://docs.scala-lang.org/overviews/jdk-compatibility/overview.html is now in place, edits/expansions welcome

Member

SethTisue commented Feb 21, 2018

a basic page http://docs.scala-lang.org/overviews/jdk-compatibility/overview.html is now in place, edits/expansions welcome

@psr

This comment has been minimized.

Show comment
Hide comment
@psr

psr Apr 25, 2018

It appears that updates to JDK 8 are going to require a license to use it in business or commercial settings beyond January 2019. The lack of support for JDK 9+ is getting more pressing!

psr commented Apr 25, 2018

It appears that updates to JDK 8 are going to require a license to use it in business or commercial settings beyond January 2019. The lack of support for JDK 9+ is getting more pressing!

@smarter

This comment has been minimized.

Show comment
Hide comment
@smarter

smarter Apr 25, 2018

@psr JDK 9+ is already supported by recent scalac and sbt releases, see https://docs.scala-lang.org/overviews/jdk-compatibility/overview.html or is there a specific feature of JDK 9+ you're looking for that is missing in scalac?

smarter commented Apr 25, 2018

@psr JDK 9+ is already supported by recent scalac and sbt releases, see https://docs.scala-lang.org/overviews/jdk-compatibility/overview.html or is there a specific feature of JDK 9+ you're looking for that is missing in scalac?

@psr

This comment has been minimized.

Show comment
Hide comment
@psr

psr Apr 25, 2018

@smarter the advice on that page still recommends using JDK 8 for compiling Scala code. Is that now no longer the case?

psr commented Apr 25, 2018

@smarter the advice on that page still recommends using JDK 8 for compiling Scala code. Is that now no longer the case?

@smarter

This comment has been minimized.

Show comment
Hide comment
@smarter

smarter Apr 25, 2018

It's recommended because it's the version that has received the most testing, but newer versions are supported. (There's a bug with macros and JDK 9+ with 2.12.5 but that will be fixed in 2.12.6: #480)

smarter commented Apr 25, 2018

It's recommended because it's the version that has received the most testing, but newer versions are supported. (There's a bug with macros and JDK 9+ with 2.12.5 but that will be fixed in 2.12.6: #480)

@psr

This comment has been minimized.

Show comment
Hide comment
@psr

psr Apr 25, 2018

Ah, that's great news.

psr commented Apr 25, 2018

Ah, that's great news.

@smarter smarter changed the title from Support JDK 9 to Support features of JDK 9+ Apr 25, 2018

@retronym retronym referenced this issue Jul 5, 2018

Open

Support JEP-261 Module System #529

0 of 4 tasks complete
@retronym

This comment has been minimized.

Show comment
Hide comment
@retronym

retronym Jul 5, 2018

Member

I've split out a ticket for JPMS support which I'm working on at the moment.

Teaser:

% 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) }")
Member

retronym commented Jul 5, 2018

I've split out a ticket for JPMS support which I'm working on at the moment.

Teaser:

% 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) }")
@denisrosset

This comment has been minimized.

Show comment
Hide comment
@denisrosset

denisrosset Jul 13, 2018

I've got compilation problems on Java 10 for https://github.com/denisrosset/symdpoly on 2.12.6.

(java.lang.AssertionError: assertion failed: ClassBType.info not yet assigned: Ljava/lang/Object)
Should I file a bug report, or is Java 10 support only preliminary?

denisrosset commented Jul 13, 2018

I've got compilation problems on Java 10 for https://github.com/denisrosset/symdpoly on 2.12.6.

(java.lang.AssertionError: assertion failed: ClassBType.info not yet assigned: Ljava/lang/Object)
Should I file a bug report, or is Java 10 support only preliminary?

@smarter

This comment has been minimized.

Show comment
Hide comment
@smarter

smarter Jul 13, 2018

Open a bug report.

smarter commented Jul 13, 2018

Open a bug report.

@ijuma

This comment has been minimized.

Show comment
Hide comment
@ijuma

ijuma Aug 8, 2018

The initial RC for Java 11 is due in 1 week. Time to file a ticket for Java 11 support? :)

ijuma commented Aug 8, 2018

The initial RC for Java 11 is due in 1 week. Time to file a ticket for Java 11 support? :)

@smarter

This comment has been minimized.

Show comment
Hide comment
@smarter

smarter Aug 8, 2018

Java 11 should work out of the box with a recent Scala and sbt, or is there a specific feature of the JDK you think scalac needs to implement?

smarter commented Aug 8, 2018

Java 11 should work out of the box with a recent Scala and sbt, or is there a specific feature of the JDK you think scalac needs to implement?

@ktoso

This comment has been minimized.

Show comment
Hide comment
@ktoso

ktoso Aug 8, 2018

We have seen an Scala issue in testing Akka against JDK11: akka/akka#25449 We are not entirely sure about it's root cause yet, please see there for details.

ktoso commented Aug 8, 2018

We have seen an Scala issue in testing Akka against JDK11: akka/akka#25449 We are not entirely sure about it's root cause yet, please see there for details.

@smarter

This comment has been minimized.

Show comment
Hide comment
@smarter

smarter Aug 8, 2018

Please open a separate issue for this

smarter commented Aug 8, 2018

Please open a separate issue for this

@ktoso

This comment has been minimized.

Show comment
Hide comment
@ktoso

ktoso Aug 8, 2018

Right sorry, you can delete my comments and we open a separate one

ktoso commented Aug 8, 2018

Right sorry, you can delete my comments and we open a separate one

@ijuma

This comment has been minimized.

Show comment
Hide comment
@ijuma

ijuma Aug 16, 2018

Java 11 should work out of the box with a recent Scala and sbt, or is there a specific feature of the JDK you think scalac needs to implement?

Aside from a method removal in Unsafe, the main new thing is http://openjdk.java.net/jeps/181. It currently requires ASM7_EXPERIMENTAL (https://github.com/scala/scala-asm/blob/s-6.2/src/main/java/scala/tools/asm/Opcodes.java#L55) to be used.

ijuma commented Aug 16, 2018

Java 11 should work out of the box with a recent Scala and sbt, or is there a specific feature of the JDK you think scalac needs to implement?

Aside from a method removal in Unsafe, the main new thing is http://openjdk.java.net/jeps/181. It currently requires ASM7_EXPERIMENTAL (https://github.com/scala/scala-asm/blob/s-6.2/src/main/java/scala/tools/asm/Opcodes.java#L55) to be used.

@adriaanm adriaanm referenced this issue Sep 18, 2018

Open

Java 11 testing #559

0 of 3 tasks complete

@adriaanm adriaanm modified the milestones: 2.12.x, 2.13.0-RC1 Sep 18, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment