> I would also suggest to pass VM options to jar util in
> test/tools/jar/multiRelease/Basic.java:
>
> 540 commands.add(jar);
> +541 commands.addAll(Utils.getForwardVmOptions());
Done.
>
> Also it seems that there is no need to compile classes using separate process:
>
> 526 String javac = JDKToolFinder.getJDKTool("javac");
>
> It is possible to use jdk/test/lib/testlibrary/CompilerUtils.java instead.
Yes, it does seem possible, and I’ll remember that in the future, but what I
have works, so I think I’ll stick with it.
>
> Thanks,
> Oleg
>
> 07.07.2016 23:32, Steve Drach пишет:
>> Hi,
>>
>> Please review the following:
>>
>> webrev: http://cr.openjdk.java.net/~sdrach/8158295/webrev.01/
>> <http://cr.openjdk.java.net/~sdrach/8158295/webrev.01/>
>> issue: https://bugs.openjdk.java.net/browse/JDK-8158295
>> <https://bugs.openjdk.java.net/browse/JDK-8158295>
>>
>> This changeset adds a multi-release jar validator to jar tool. After the
>> jar tool builds a multi-release jar, the potential resultant jar file is
>> passed to the validator to assure that the jar file meets the minimal
>> standards of a multi-release jar, in particular that versioned classes have
>> the same api as base classes they override. There are other checks, for
>> example warning if two classes are identical. If the jar file is invalid,
>> it is not kept, so —create will not produce a jar file and —update will keep
>> the input jar file.
>>
>> Thanks
>> Steve
>
>
