RFR [6943190] TEST_BUG: java/lang/Runtime/exec/ExecWithInput.java hardcodes path to cat (original) (raw)

Martin Buchholz martinrb at google.com
Mon Mar 17 18:31:40 UTC 2014

The latest webrev looks pretty good.

It matters very little, but I agree with Alan that we should send messages about not being able to find dependencies to stdout.

Test isolation is always a compromise. I would use othervm only when we are polluting global state during a successful run. Because test performance matters.

On Mon, Mar 17, 2014 at 2:06 AM, Ivan Gerasimov <ivan.gerasimov at oracle.com>wrote:

Thank you Alan!

On 17.03.2014 11:50, Alan Bateman wrote: On 16/03/2014 16:52, Ivan Gerasimov wrote:

Would you please take a look at the updated webrev with your suggestions incorporated: http://cr.openjdk.java.net/~igerasim/6943190/3/webrev/ Ivan - I see that a number of the tests have been changed to /othervm and I'm wondering what the reason for this is. Clearly tests for Process will be launching new VMs but it would be great if we could avoid having to launch a VM for the test "main" too. These two tests used the commands run from non very common location (/usr/bin/ instead of /bin/), so I suspect they have been rarely run. As it follows from the summaries, one of them ensures the VM doesn't crash; the other checks, whether the input/output streams are left open. Both tests in the case of a failure could interfere with other tests unless they run in the othervm mode. That's why I thought it's better to add the flag. Another general comment is that if a command is not found the tests will now pass and the only way to know that anything has gone wrong is to look in the .jtr file. I would personally prefer the tests to fail so that any issues in the environment or special-casing for new ports can be found quickly. I've tried not to change the tests' logic too much. For example, in test/java/lang/Runtime/exec/ConcurrentRead.java, if 'tee' hadn't been found, the test just silently exited. And I only added some debug output about that fact. Otherwise, if we treat the 'tee' absence as an error, we may start seeing failures in different environments, which would not be related to ConcurrentRead.java itself. IMO ideally, there should be a configurable part of the harness, where all the shell commands are set up. So that they could be accessed by both Java and shell-based regtests. For the Linux or Solaris-only tests then the tests now output an information message via System.err, I assume this should be System.out as it's not really an error or usage message. Fixed it. On the places to search then I'm wondering about /system/bin. Is that needed? I assume that if there is a port to an operating system that uses this location then it will be added as part of the port. -Alan. Sincerely yours, Ivan

More information about the core-libs-dev mailing list