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

Martin Buchholz martinrb at google.com
Mon Feb 24 19:38:22 UTC 2014


Thanks for working on these ancient Process tests.
I would prefer to see them using "feature tests".

You wanna do "cat /dev/zero"?  Then look for cat in /bin and /usr/bin and
check for /dev/zero as well, e.g. using File.isExecutable

Doing OS-specific things like:

+    static final boolean isLinux =
+            System.getProperty("os.name", "unknown").startsWith("Linux");


should be a last resort.


On Mon, Feb 24, 2014 at 9:26 AM, Ivan Gerasimov
<ivan.gerasimov at oracle.com>wrote:

> Hello!
>
> We've got one quite old report about been unable to run the test under
> Android.
> https://bugs.openjdk.java.net/browse/JDK-6943190
>
> That was due to hard-coded path to the cat utility as /bin/cat.
> When investigating, I found two other tests under the same directory that
> use /usr/bin/cat and /usr/bin/echo.
> These two test seem to (almost) never run because of the unusual path.
>
> Here's the first version of the webrev, with the fix to only three tests
> mentioned above:
> http://cr.openjdk.java.net/~igerasim/6943190/0/webrev/
>
> java/lang/Runtime/exec/ directory has also got several other tests, which
> run shell commands.
> Some of them have absolute path and some of them don't.
>
> So I have a general question: Why would we ever need the absolute path for
> the commands?
> Why wouldn't we rely on the PATH env variable?
>
> Sincerely yours,
> Ivan
>
>
>



More information about the core-libs-dev mailing list