support `JEP 476: Module Import Declarations` in `JavaParsers`

[xuwei-k]

Reproduction steps

https://openjdk.org/jeps/476

Scala version: 2.13.14

$ java --version
openjdk 23-ea 2024-09-17
OpenJDK Runtime Environment (build 23-ea+25-2094)
OpenJDK 64-Bit Server VM (build 23-ea+25-2094, mixed mode, sharing)

B.scala

class B

A.java

import module java.base;

public class A {
}

build.sbt

javacOptions ++= Seq("--enable-preview", "--release", scala.util.Properties.javaSpecVersion)

scalaVersion := "2.13.14"

project/build.properties

sbt.version=1.10.0

Problem

run sbt compile

[error] my-example-project-path/A.java:1:15: `;` expected but identifier found.
[error] import module java.base;
[error]               ^
[error] one error found
[error] (Compile / compileIncremental) Compilation failed

workaround

set compileOrder := CompileOrder.JavaThenScala or compileOrder := CompileOrder.ScalaThenJava in sbt

[som-snytt]

The Java feature is mostly about prototyping and JShell. It would be nice if -Yimports handled modules.

scala -Yimports:java.lang,scala,scala.Predef,scala.annotation,scala.util.chaining becomes scala -Yimports:java.base,scala,scala.Predef,scala.annotation,scala.util.chaining where for conflicts between module and package names it could support scala -Yimports:module java.base,etc or someday just scala -Yimports:java.base,scala.base

[SethTisue]

would it be useful for our parser to accept but ignore such imports? or does it need to actually take action in order for the change to be useful?

[xuwei-k]

finalized in JDK 25

• https://openjdk.org/jeps/511
• https://github.com/openjdk/jdk/pull/23801

[retronym]

If we parsed these, but did not desugar them to the equivalent import statements, we'd have to mark all definitions in the file with an ErrorType, so any usage of them by co-compiled Scala code would flag as an error.

This is perhaps useful for some use case but not really something we'd be proud to ship!

To desugar the import, we'd need to revive our effort to read the JPMS module defininitions (from module-info.java and the corresponding class file), and implement some of the module resolution logic