Future proofing use of ct.sym from Scala compiler

[Jason Zaugg]

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/20180305/179c8a8e/attachment.html>