Support features of JDK 11+

[retronym]

In general, Scala now works just fine on JDK 11

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

JDK9 JEP list

• JEP 223: New Version-String Scheme
  • [x] Update our version parsing in isJavaAtLeast (and elsewhere?) https://github.com/scala/scala/pull/5276
• JEP 220: Modular Run-Time Images (includes SI-9103)
  • [x] Adapt our classpath to use jrt:/ virtual filesystem. WIP retronym:review/5112
  • [ ] 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://)
  • [ ] Adapt REPL :javap command (currently gets IllegalArgumentException in JavapClass$JavapTool$.apply(JavapClass.scala:337)
• JEP-261 Module System (https://github.com/scala/scala-dev/issues/529)
  • [ ] javac allows programmers to declare module requirements, exports inline in the sourcetree ("module-info.java" files). What should we do?
  • [ ] app class loader is no longer a URLClassloader. Lots of places enumerate the classpath for JARs to initialize settings for a compiler. Experiment, document.
  • [ ] Update classfile reader to parse module-info.class (perhaps using ASM)
  • [ ] create module readability / accessibilty graph (following transitive "public exports")
• JEP-238 Multi-Release JAR Files
  • [x] See if this feature is used in practice
  • [x] Update classpath implementation to be able to consume such JARs. (WIP)
• JEP 280: Indify String Concatenation
  • [x] Under target:jvm-1.9, consider emitting Javac style string concat with indy.
  • https://github.com/scala/scala/pull/9556
  • [x] Update to ASM 5.1 (?). As suggested by @varming https://github.com/scala/scala-asm-legacy/pull/11
  • [ ] JEP-193 VarHandles introduce a number of new methods annotated with @PolymorphicSignature. Expand our compiler support to these methods.
  • [ ] Maybe: foster creation of a library of Java 8/9 shims that use invokedynamic to use some Java 9 features (e.g VarHandle) when available but fall back to Java 8 alternatives (e.g. Unsafe._), as prototyped in https://github.com/retronym/scala/commit/a95f03e8b86c1c28f4a86346697ae0ff5629dfc4
• Infrastructure:
  • [x] Make JDK9 EA builds available in CI: https://github.com/scala/scala-jenkins-infra/issues/174
  • SBT
  • [ ] Review Zinc's use of sun.boot.classpath: https://github.com/sbt/zinc/blob/1.x/internal/zinc-compile-core/src/main/scala/sbt/internal/inc/CompilerArguments.scala#L83
  • Make mixin fields non-final to avoid verify errors. Use explicit fences to preserve memory effects: #408

[SethTisue]

@retronym I'm retargeting this for 2.13.1, please open new tickets for any pieces that must make 2.13.0-RC1 or 2.13.0

[cekvenich]

It has been almost a year. Is there any ETA on JDK 11 support? Or we wait for Scala 3?

[smarter]

@cekvenich Scala 2 works on JDK 11 already, this bug report is about specific new features of the JDK that could be supported, are you interested in one of these features in particular?

[cekvenich]

@smarter No. I was just planning on installing Scala, and home pages says use Java 8, but I already have 11 and did not want issues. So should work w/11. OK, thanks.

[SethTisue]

perhaps it's time for us to tone down or remove the JDK 11 cautions at https://www.scala-lang.org/download/ and https://docs.scala-lang.org/overviews/jdk-compatibility/overview.html#jdk-11-compatibility-notes . the current language in both locations was put in place quite some time ago

[SethTisue]

I've added "In general, Scala now works just fine on JDK 11" right at the top of this page.

I also changed the ticket title and tags to reflect that we don't care about 9 and 10 anymore, only 11 and higher.

[schrepfler]

Does the "just works" cover running on top of JDK 11 or also developing on top of it? I remember having some issues around module support with the satellite scala packages (java8-compat, scala-parser-combinators etc.) when trying to build stuff on it (I was on JDK 13 when I was trying this).

[nigredo-tori]

@schrepfler, I've been developing/running on top of JDK 11 for a while now (both with 2.11 and 2.12, and with some Java libraries in the mix). Most of the issues I encounter are caused by external libraries not built for Java 11 (e.g. ByteBuffer API has changed somewhere between 8 and 11), missing modules (solved by adding them to classpath as managed/unmanaged dependencies), and class loader changes. JPMS is not an issue unless you want to really dig into it and build your own modules.

Basically, nothing prevents you from working with JDK 11. You'll encounter some annoying issues - but those are not unique to Scala. Some JPMS-related features are not supported - but everything that was possible with JDK 8 should be possible with JDK 11 after some fiddling.

[SethTisue]

@schrepfler it's not uncommon for a random Scala OSS repo to fail to build on JDK 13 without tweaks, usually trivial ones like bumping the SBT version or disambiguating a now-ambiguous import, that kind of thing. so if you're working in other people's repos, you'll probably want to have JDK 8 and/or 11 on your system as a fallback plan, in case the needed tweaks aren't obvious

some repos may also fail to build on 11, but I think that has become much less common

I agree with @nigredo-tori 's remarks as well.

[raboof]

external libraries not built for Java 11 (e.g. ByteBuffer API has changed somewhere between 8 and 11)

(kindof offtopic, but since it was mentioned: if a library has a problem with ByteBuffer.clear when running under JDK8, this is likely because it was built with JDK11 targeting JDK8, but using the JDK11 bootclasspath. Using the --release/-release flags for javac/scalac while compiling the library that calls ByteBuffer.clear should fix this, but IIRC there was some problem with this on scalac versions before 2.12.8/2.13.1)