Future proofing use of ct.sym from Scala compiler

[Jonathan Gibbons]

Filed as https://bugs.openjdk.java.net/browse/JDK-8199521

-- Jon

On 3/4/18 4:49 PM, 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.
>
> 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?
>
> 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.
>
> Side note: It would certainly be helpful to expose something like 
> `jrt://` for this historical data. The closest I could get via public 
> 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
>
>

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