Future proofing use of ct.sym from Scala compiler

[Jason Zaugg]

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.

Regards,

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