RFR 8149757:Implement Multi-Release jar aware JavacFileManager for javac

[Jonathan Gibbons]

On 04/06/2016 11:40 AM, Jan Lahoda wrote:
> -where there consideration on how this will work with other file 
> managers? (Esp. given the instanceof in Main?) The other file manager 
> may be a relatively simple wrapper over the JavacFileManager (an 
> example would be:
> http://hg.openjdk.java.net/jdk9/dev/langtools/file/329ae120e365/src/jdk.jshell/share/classes/jdk/jshell/MemoryFileManager.java 
>
> )
>
> Seems to me that maybe using isSupportedOption("multi-release") 
> instead of the instanceof would provide a more seemless integration.

Yes, but ...  this reduces to a previously unsolved problem (which we're 
working on.)   We have no precedent at this point for mandating options 
on StandardJavaFileManager, or even the half-way point of, if you 
support this option, here's what the semantics might be.   Yeah, we 
don't even currently do it for -classpath, -sourcepath etc.

Currently, the thinking is that the code path is primarily for the 
command line usage, when we know it will be JavacFileManager.  If you're 
in the API and using your own custom file manager, you can configure the 
file manager directly.


>
> -why is JavacFileManager.getJarFSProvider() needed? Shouldn't
> FileSystems.newFileSystem(realPath, env);
> be enough? (Calling an SPI directly from an API client seems 
> suspicious to me.)

If I recall correctly, the NIO2 API design forced this one. The method 
you are referring to does not exist. There is only one that takes a URI, 
and that has very different semantics.  So we had to go with the method 
on the provider, hence the use of getJarFSProvider.


>
> -for Jon's comment on converting Target to a number, 
> JDKPlatformProvider uses:
> Integer.toString(target.ordinal() - Target.JDK1_1.ordinal() + 1)

Using ordinals is almost as bad as using strings ;-)  In general, the 
practice in langtools has been to avoid use of .ordinal where possible.

>
> But a method on Target providing the number would be better, of course.
>
> Jan
>
> On 5.4.2016 23:02, Steve Drach wrote:
>> Hi,
>>
>> Please review the changes required to make javac and the
>> StandardJavaFileManager multi-release jar aware.  For javac, the version
>> of the classes in a multi-release.jar is selected by the -release (or
>> -target) command line option, or if the option is not present, javac’s
>> default policy is used to select the version — typically the runtime
>> version (i.e. version 9 is selected for JDK 9).  For the
>> StandardJavaFileManager, the version is selected with the handleOption
>> method.  See the tests for more detail.
>>
>> issue: https://bugs.openjdk.java.net/browse/JDK-8149757
>> webrev: http://cr.openjdk.java.net/~sdrach/8149757/webrev/index.html
>>
>> Thank you,
>> Steve