So long bootclasspath!

[Stephane Epardaud]

Well… turns out we were using it :(

We have a weird situation with Ceylon which is that we include a forked
javac (based on 1.7 with backports from 1.8), along with
javax.lang.model, which allow us to both compile and run in Java 7 and
Java 8. And we use the bootclasspath to tell the JVM to use ours when we
run the Ceylon compiler. Now, I understand that's bad form to fork and
keep the package name, and that it hides the real javac but in practice
that has never been a problem to us. And it allows us to rebase on new
JDKs much more easily than if we rename.

I tried to compile our code with Java 9 + Jigsaw and gave up after a
day, because the boot classpath is gone, so I figured well, let's bite
the bullet and rename our fork, but now our javac code is in
com.foo.javac and it can't see sun.reflect.annotation that javac uses. I
also had to remove the javax.lang.model classes we used to ship, but
that means we can't retrofit it so that our javac fork compiles in both
Java 7 and 8 (since it requires new APIs only available to Java 9 users).

I understand that's an uncommon situation (the fork), but that's what it
is, because we had to make tweaks here and there that would not make any
sense to push upstream.

Under Jigsaw, would it still be possible for us to ship javac and
javax.lang.model packages unrenamed? If yes, how? If no, do you have any
idea how else we could do? I suppose we could fork+rename both the
jdk.compiler and java.compiler modules (holds javax.lang.model), but
that won't let us access APIs such as sun.reflect.annotation which is
only granted to jdk.compiler…

On the brighter side, I've managed to make our javac fork work with
jimage pretty easily thanks to that "jrt:/" FS, that was a pretty good
idea guys (but then again, I've found most of the javac code to be quite
clever).

Cheers.