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