RFR  TEST_BUG: java/lang/Runtime/exec/ExecWithInput.java hardcodes path to cat
ivan.gerasimov at oracle.com
Mon Mar 17 09:06:53 UTC 2014
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:
> 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
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.
> 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.
More information about the core-libs-dev