Future proofing use of ct.sym from Scala compiler
Jason Zaugg
jzaugg at gmail.com
Tue Mar 6 00:09:11 UTC 2018
On Tue, 6 Mar 2018 at 06:15 Jonathan Gibbons <jonathan.gibbons at oracle.com>
wrote:
>
> At least for StandardJavaFileManager, the trend has been to increase
> interoperability with the java.nio.file API, by making it possible to
> get java.nio.file.Path objects for Locations and FileObjects, thus
> allowing the use of java.nio.file API for all the otherwise "missing"
> API on (Standard)JavaFileManager.
>
These are certainly welcome.
I took a fresh look at what is possible, and got much closer to my ultimate
goal of letting JavacFileManager do all the dirty work of dealing with
ct.sym and MR JARs (not to mention --patch-module / --module-path etc)
https://gist.github.com/2d1f8ab484427d032dc99bbbced92861
The missing link is JDKPlatformProvider, which is not exposed in
javax.tools. Would be be possible to expose this? JDKs that don't want to
support platform versioning would be only need to accept the running JDK
version. I'll be able to workaround this in the meantime at the cost of
coding against the ct.sym format.
Regards,
Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20180306/9a45b03e/attachment.html>
More information about the compiler-dev
mailing list