>>> 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.
>
> In this case it is also needed to pass the jtreg's javac options
> ("test.compiler.opts”).
OK
>
> - Oleg
>>
>>> 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
>>>
>
