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

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