RFR 8149757:Implement Multi-Release jar aware JavacFileManager for javac
steve.drach at oracle.com
Wed Apr 6 20:22:37 UTC 2016
>> -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.
>> On 5.4.2016 23:02, Steve Drach wrote:
>>> 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,
More information about the compiler-dev