Future proofing use of ct.sym from Scala compiler

[Jan Lahoda]

Hi Jason,

On 5.3.2018 01:49, Jason Zaugg wrote:
> I hope its okay to pose this question here, please let me know if there
> is a more appropriate list.
>
> I am adding support for JEP 247 (Compile for Older Platform Versions) to
> the Scala compiler. Together with support for multi-release JARs, we'll
> have a working --release compiler option like javac.
>
> JEP-247 doesn't specify the format of ct.sym, I understand this is an
> implementation detail of the JVM.

Yes, I don't think the format is currently considered to be stable.

>
> In any case, ct.sym has a straightforward enough structure that we can
> code against it directly. I'd like to future proof this implementation
> as much as possible.
>
> What is the plan for encoding the versions into the ZIP entry name once
> in JDK 11+, at which point the "10" becomes a historical version and the
> assumption in CreateSymbols.java of: "Note: the versions are expected to
> be a single character." is violated? Will a delimiter be added
> ("10_9_8") or will the code that interprets this path name be updated to
> be able perform a smart parse of "1098"? If the latter, what rules would
> be used?

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'.

>
> I see that support was recently added [1] to version module-info.class.
> That aspect of the changed didn't seem to generate discussion in the
> review [2], but if there is anything subtle about the way module
> metadata is versioned, please let me know.

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.

>
> 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?

Jan

> APIs was with the javax.tools API, but this hardcodes `--release` to the
> running JDK version (or was it the --release of the running JVM?)
>
> Beyond that issue, the JavaFileManager API doesn't let one find the
> direct sub-packages of a given package without performing a
> full recursive walk of the contained class/source files, which is
> problematic for our use case.
>
> Thanks,
>
> Jason Zaugg
>
>
> [1] http://hg.openjdk.java.net/jdk/jdk/rev/dbfac941197a#l159.224
> [2]
> http://mail.openjdk.java.net/pipermail/compiler-dev/2017-October/thread.html#11183
>
>