RFR 8149757:Implement Multi-Release jar aware JavacFileManager for javac
Jan Lahoda
jan.lahoda at oracle.com
Wed Apr 6 18:40:17 UTC 2016
-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
More information about the compiler-dev
mailing list