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.
