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

[Steve Drach]

Hi,

Thanks for the comments.  For the moment, “stay tuned”, I’ll have to figure out how to do some of this.  I’m not very familiar with the code.

> On Apr 6, 2016, at 11:40 AM, Jan Lahoda <jan.lahoda at oracle.com> 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.
> 
> -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.)
> 
> -for Jon's comment on converting Target to a number, JDKPlatformProvider uses:
> Integer.toString(target.ordinal() - Target.JDK1_1.ordinal() + 1)
> 
> 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