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

[Steve Drach]

>> -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.

That’s correct.







> 
> 
>> 
>> -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
>