Future proofing use of ct.sym from Scala compiler

Jason Zaugg jzaugg at gmail.com
Tue Mar 6 00:09:10 UTC 2018

On Tue, 6 Mar 2018 at 02:46 Jan Lahoda <jan.lahoda at oracle.com> wrote:

> The idea is to use letters as digits over 10 ('A', 'B', etc.). Does not
> have to be a hexadecimal number, could continue with 'G' after 'F'.

Roger that, I'll teach our compiler about that encoding.

> There is a possible subtlety in how the system module path is
> constructed. It may be something like:
> for module "java.base": 9-modules/java.base, 9, 89, ...
> for module "java.compiler": 9-modules/java.compiler, 9, 89, ...
> But the directories like "9" contain classfiles (.sig files) for all
> modules, not only for the given specific module. javac will only read
> classfiles for the packages the given module exports.

Thanks, I'll keep that in mind when implementing JPMS (that's my next job
after the lower hanging fruit of --release)

> >
> > Side note: It would certainly be helpful to expose something like
> > `jrt://` for this historical data. The closest I could get via public
> I think that this is something to consider. In this case, would it be
> enough to get access to ct.sym of the current runtime JDK?

See my other email in the thread which discusses the possibility of
exposing the functionality of JDKPlatformProvider via a supported API.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20180306/5bba5a2d/attachment.html>

More information about the compiler-dev mailing list