Using JAVA_OPTIONS for tools is conceptually wrong.
JAVA_OPTIONS is specifically intended to pass options to VM instances,
as created by a "java" command. It is not intended that you should
prefix the options with -J and use them for arbitrary tools.
The code in the webrev is also perverse for taking the trouble to split
the string to a stream, collect the results into a list, convert the
list back into a stream again and use .forEach.
You could do better, and much simpler, with something like
if (!option.isEmpty()) {
commands.addAll(Arrays.asList(option.split("\\s+",-1)));
}
-- Jon
On 05/25/2016 10:48 AM, Martin Buchholz wrote:
Hi Andrey,
Looking at http://openjdk.java.net/jtreg/vmoptions.html,
I see we have both test.vm.opts and test.tool.vm.opts
and the latter is supposed to take care of adding "-J".
+ VM_OPTIONS.stream().map(opt -> "-J" + opt).forEach(commands::add);
+ JAVA_OPTIONS.stream().map(opt -> "-J" + opt).forEach(commands::add);
---
Maybe splitting on "\\s+" would be better.
---
I think we should have test library methods to return the List<String>
for java subprocesses, one that could try hard to get the option
tokenization correct.
---
On Wed, May 25, 2016 at 9:07 AM, Andrey Nazarov
<andrey.x.naza...@oracle.com> wrote:
Some jar tests start VMs without passing vmoptions from jtreg.
This fix pass jtreg's vmoptions and javaoptions to processes(java, jar,
javac) started by tests.
webrev: http://cr.openjdk.java.net/~anazarov/8157850/webrev.01/
jbs: https://bugs.openjdk.java.net/browse/JDK-8157850
--Andrey
