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