Future proofing use of ct.sym from Scala compiler

Jonathan Gibbons jonathan.gibbons at oracle.com
Tue Mar 6 01:11:44 UTC 2018


PlatformProvider, and JDKPlatformProvider addresses some use cases that 
are probably no longer relevant.

I don't think we want to directly expose that functionality in javax.tools.

However, I agree it is interesting to ensure that we can get at the 
functionality for supporting different versions of the platform, 
including the underlying mechanisms of ct.sym and MR-jars, but as much 
as possible I think we should work within the existing javax.tools API 
... for example by setting options of a file manager.

Is there anything specific on JDKPlatformProvider you are looking to 
use/support that could not be part of an enhanced file manager?

-- Jon


On 03/05/2018 04:09 PM, Jason Zaugg wrote:
> On Tue, 6 Mar 2018 at 06:15 Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto: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/20180305/ff7cecab/attachment-0001.html>


More information about the compiler-dev mailing list