RFR: JDK-8186087: jar tool fails to create a multi-release jar when validating nested classes
Paul Sandoz
paul.sandoz at oracle.com
Wed Nov 29 00:31:24 UTC 2017
+1
Validator
--
365 public static void main(String[] args) throws IOException {
366 System.out.println("validating: " +
367 new Validator(new Main(System.out, System.err, "validator"),
368 new ZipFile(args[0]))
369 .validate());
370 }
Left over from debugging?
Paul.
> On 27 Nov 2017, at 18:57, Xueming Shen <xueming.shen at oracle.com> wrote:
>
> Hi
>
> Please help review the change for #8186087
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8186087
> webrev: http://cr.openjdk.java.net/~sherman/8186087/webrev
>
> The proposed change is to handle the "outer class" of a nested class correctly, instead of simply
> relying on "top level" class. Other than that, a "minor" change is to also stop trying to "validate"
> the non-class/resource entries, for example, if you have a resource "foo" both in the base and
> versioned directory, and with different "content", currently implementation throws a warning
> message, which does not appear to be desired and appropriate.
>
> There is a "known/open" issue during discussion regarding how to handle the entry that its class
> name does not match its entry name (for example, class p.foo.class is located at bar/p/foo.class,
> currently jar.validator fails the validation with error msg). It appears to be a separate issue, so
> I'm leaving that one of this one for now.
>
> Thanks,
> Sherman
More information about the core-libs-dev
mailing list