The question here is: should we also get rid of ClassFileLookup, which "abstract over how class file lookup is performed in different classpath representations". There's a single implementation now (FlatClassPath).

https://github.com/scala/scala/blob/12c7fbdf39ccd638d056cd43bd4dbf1772409995/src/compiler/scala/tools/nsc/util/ClassFileLookup.scala

I guess we will need a new implementation for Java >= 9 ... but whether the abstraction as given makes sense ... no idea. I'd probably remove it, and add a comment so that the person implementing Java 9 support is aware of it.

@lrytz I've hacked together happy path support Java 9 / Jigsaw based on this PR:

https://github.com/scala/scala/compare/dd3fa5b...retronym:review/5112?expand=1

There is a backend crash in the REPL under power mode (see the commit comment for a transcript) that I don't understand. Might be worth a quick look to see if you can see what's going on.

I would then vote to remove the unneeded abstraction layers, as it doesn't look like they are needed to support Jigsaw.

@retronym Looks great!
Just wondering ... as far as I remember, Oracle licensed the filesystem code under an acceptable license. Would it make sense to ship that file so that jimage files can be read, even when running scalac on Java 8?

@soc Yeah, that would be ideal.

There is a backend crash in the REPL under power mode (see the commit comment for a transcript) that I don't understand. Might be worth a quick look to see if you can see what's going on.

I've pushed a fix to my branch, it was a dumb mistake in my patch.

Mhh, I thought they had published such a jar file ... I can't find it anymore. In the worst case the recommendation seems to be that the compiler loads jrt-fs.jar from a JDK9 installation.

That might be annoying with the current tooling (but less annoying with the sbs tool I'm working on).

There is a http://mail.openjdk.java.net/pipermail/jigsaw-dev/2014-November/004056.html

Yes, found that, too. But that has the GPL license because it is just extracted from the OpenJDK repo.

@lrytz I've updated my branch with my suggested refactorings to eliminate the now-unused abstraction between legacy and flat classpaths.

I renamed FlatClasspath to scala.tools.nsc.util.ClassPath and left the other implementation details in nsc.classpath._.

This will require an patch to partest, which has a type alias to Classpath: https://github.com/scala/scala-partest/blob/master/src/main/scala/scala/tools/partest/package.scala#L19. This is a good example of why @soc's suggestion to in-source partest's code into scala/scala has merit.

for partest: type ClassPath[T] = scala.tools.nsc.util.ClassPath[T] is unused, val ClassPath = scala.tools.nsc.util.ClassPath is used only for the join and split methods. so in this case here it should be enough to just remove the type alias to get source compatibility. binary compatibility doesn't even break.

thanks for the follow-up work, great stuff!

should I cherry-pick the last commit (5e07d57) and push it here?

Yep, let's that would be good. Sorry I didn't leave a cleaner history, but it would be ideal to keep the Java 9 stuff as an separate commit (or maybe separate PR)

allright thanks! think a separate PR for the Java 9 support would make sense - does it even compile on Java 8? you're not using any Java 9 API?

On Java 8, you get a NIO exception when looking up the jrt:/ filesystem, which my code handles.

But regardless, a separate PR makes sense.

@retronym should be ready now

Aside from the s/classFileLookup/classPath comment, this looks ready to me.

ok, renamed classFileLookup.

LGTM, sorry about the slow final review. and thanks again for moving this forward!

This was https://issues.scala-lang.org/browse/SI-9709