RFR 8149757:Implement Multi-Release jar aware JavacFileManager for javac
Jonathan Gibbons
jonathan.gibbons at oracle.com
Wed Apr 6 18:23:27 UTC 2016
Steve,
The most noticeable ickiness is the following string bashing on the name
of the Target enum constant,
249 List<String> list = List.of(target.toString().replace("JDK1_", ""));
It's not wrong, but it is fragile, as we've already considered renaming
Target.JDK1_9 to Target.JDK9.
A somewhat more robust solution would be to use a regex [1]:
249 List<String> list = List.of(target.toString().replaceAll("^JDK(1_)?", ""));
The gold-star solution would be to have a method on Target to return the
MR-version number.
-- Jon
[1]
http://blog.codinghorror.com/regular-expressions-now-you-have-two-problems/
On 04/05/2016 02:02 PM, 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
> <http://cr.openjdk.java.net/%7Esdrach/8149757/webrev/index.html>
>
> Thank you,
> Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20160406/2c22ad57/attachment-0001.html>
More information about the compiler-dev
mailing list