22.07.2016 23:35, Steve Drach пишет:
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").
- 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
