JDK9: Support module-info.java

[ktoso]

Ticket originates from discussion with Scala team how to handle the module-info.java of Jigsaw in Scala builds.

Scala will not get it's own special syntax for these files, as @retronym correctly observed that the syntax is more of its "own thing". Looks kind of like protobuf rather than any of scala/java, so seems we'll use the same syntax.

• This means that mixed language projects will put the file into src/main/java, so sbt should be able to pick this up (not 100% sure yet what this implies, perhaps just a simple "compile it")
• For just Scala projects though, it would be a pain to have to put and recreate package structure in parallel to the one in src/main/scala only to put the single module-info file there, it would also be a bit harder to find for people browsing the code. Therefore I'd propose to be able to notice that there's a module-info.java file even if it lives under src/main/scala and treat it in that special way - (compile with javac I guess?)

This is lose thought for now, feel free to sanity check my assumptions and challenge ideas :)

[richdougherty]

Instead of supporting a .java file in the module-info.java directory, you could also have a small DSL in sbt to generate the file (and then automatically compile it with javac). sbt could automatically work out the module dependencies for a project and generate these automatically. The user could override these and add opens/exports information.

^^^ Not a fully thought out idea, but perhaps worth considering.

[retronym]

sbt/zinc#522 avoids a crash in Zinc's when module-info.java files are compiled.

I think SBT already lets you stick .java files under src/main/scala and it seems to just work.

We'll almost certainly need to use the --patch-module options for javac and java when to deal with src/main and src/test code compiling into the same module. https://github.com/micromata/sawdust documents how to configure various build tools to do this, we should submit a PR to that project to document how it works for SBT (once we figure it out!)

[retronym]

The output from one of the build tools showcased is quite instructive:

⚡ jshell build.jsh

 build

treeDelete(root:'target/bach')

 compile main modules

running javac with 15 argument(s)
javac
-deprecation
-d
  target/bach/main
-encoding
  UTF-8
-Werror
--module-path
  deps
--module-source-path
  modules/sawdust.alpha/src/main/java
-parameters
modules/sawdust.alpha/src/main/java/sawdust.alpha/module-info.java
modules/sawdust.alpha/src/main/java/sawdust.alpha/sawdust/alpha/AlphaMain.java
modules/sawdust.alpha/src/main/java/sawdust.alpha/sawdust/alpha/AlphaProtected.java
modules/sawdust.alpha/src/main/java/sawdust.alpha/sawdust/alpha/AlphaPublic.java

 run main

running java with 4 argument(s)
java
--module-path
  target/bach/main:deps
--module
  sawdust.alpha/sawdust.alpha.AlphaMain
replaced java with /Library/Java/JavaVirtualMachines/jdk-10.jdk/Contents/Home/bin/java
[main] INFO sawdust.alpha.AlphaMain - class initialized
[main] INFO sawdust.alpha.AlphaMain - sawdust.alpha.AlphaPublic@544fe44c
[main] INFO sawdust.alpha.AlphaMain - sawdust.alpha.AlphaProtected@3327bd23

 compile test modules

running javac with 18 argument(s)
javac
-deprecation
-d
  target/bach/test
-encoding
  UTF-8
-Werror
--patch-module
  sawdust.alpha=modules/sawdust.alpha/src/main/java/sawdust.alpha
--module-path
  deps
--module-source-path
  modules/sawdust.alpha/src/test/java:modules/user.view/src/test/java
-parameters
modules/sawdust.alpha/src/test/java/sawdust.alpha/module-info.java
modules/sawdust.alpha/src/test/java/sawdust.alpha/sawdust/alpha/AlphaProtectedTests.java
modules/sawdust.alpha/src/test/java/sawdust.alpha/sawdust/alpha/AlphaPublicTests.java
modules/user.view/src/test/java/user.view/module-info.java
modules/user.view/src/test/java/user.view/user/view/UserViewTests.java

 launch junit platform console

running java with 7 argument(s)
java
--module-path
  target/bach/test:deps
--add-modules
  ALL-MODULE-PATH
--module
  org.junit.platform.console
--scan-modules
replaced java with /Library/Java/JavaVirtualMachines/jdk-10.jdk/Contents/Home/bin/java
╷
└─ JUnit Jupiter ✔
   ├─ [user.view] UserViewTests ✔
   │  └─ accessExportedTypes() ✔
   ├─ [sawdust.alpha] AlphaProtectedTests ✔
   │  └─ simpleNameIsAlphaProtected() ✔
   └─ [sawdust.alpha] AlphaPublicTests ✔
      └─ simpleNameIsAlphaPublic() ✔

Test run finished after 48 ms
[         4 containers found      ]
[         0 containers skipped    ]
[         4 containers started    ]
[         0 containers aborted    ]
[         4 containers successful ]
[         0 containers failed     ]
[         3 tests found           ]
[         0 tests skipped         ]
[         3 tests started         ]
[         0 tests aborted         ]
[         3 tests successful      ]
[         0 tests failed          ]

[retronym]

First steps towards the SBT version:

I'm seeing an SBT hang trying to run the compile task. At tag sbt-hang:

⚡ java_use 1.8; sbt
[info] Loading settings from dirtymoney.sbt,gpg.sbt,idea.sbt ...
[info] Loading global plugins from /Users/jz/.sbt/1.0/plugins
[info] Loading project definition from /Users/jz/code/sawdust/project
[info] Loading settings from build.sbt ...
[info] Set current project to root (in build file:/Users/jz/code/sawdust/)
[info] sbt server started at local:///Users/jz/.sbt/1.0/server/97db45062e4dcdf36c4b/sock
sbt:root> compile

Ends up hung: https://gist.github.com/1adebe9a1212d2bf7a8805f5ed7f9e17

[retronym]

That minimizes to what I suppose is user error:

// build.sbt
javacOptions in Compile ++= {
  (fullClasspath in Compile).value
  Nil
}

sbt compile hangs in SBT 1.1.2 and 0.13.17.

Is there a cycle here? If so, is a hang expected?

[dwijnand]

Is there a cycle here?

yep, fullClasspath is dependencyClasspath ++ compile products (technically exportedProducts) so it definitely transitively depends on javacOptions which is a compileOptions (and thus a compileInputs).

If so, is a hang expected?

no, a cycle exception thrown at load time is expected, at least to me.

[theogiraudet]

Is module-info.java supported in the new versions in the new versions?

[UkonnRa]

+1 any update?

[dkovalenko]

Any instructions to how build sbt scala project with module-info.java ?

[SethTisue]

has anybody tried compileOrder := CompileOrder.JavaThenScala as a way of keeping scalac from blowing up trying to process the .java source?

[retronym]

A long time ago, I put together some alpha-quality support for SBT+JPMS in https://github.com/retronym/sbt-jpms. Could be time to take another swing at this problem.