Future proofing use of ct.sym from Scala compiler

Jonathan Gibbons jonathan.gibbons at oracle.com
Tue Mar 13 15:38:33 UTC 2018

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>

More information about the compiler-dev mailing list