(Bugid 4202425 covers this situation, but it was closed as a result of some
 invalid reasoning from false premises, so I'm resubmitting with a counter-
 argument.)

If the PATH contains "/home/user/netscape" before
"/js/files/JDK1.2_latest/solaris/bin", and the directory
"/home/user/netscape/java" exists, then Runtime.exec("java -fullversion")
will fail whereas Runtime.exec("env java -fullversion") will succeed.

The code in src/solaris/native/java/lang/UnixProcess_md.c searches the PATH
in a nonstandard way: as soon as it finds a directory with the same name as
the target command, it aborts with an error message such as
"java: cannot execute". Because the shells do not do this, the root cause is
highly nonobvious.

Bugid 4202425 was closed as not-a-bug. The evaluation by hzhang@eng says
because the JLS is silent on Runtime.exec()'s semantics, this is not a bug.
On the contrary, the exec() semantics are defined by the implementation OS.
For Solaris (and other Unix variants), the correct model is execvp(3) (but
/bin/sh is good too).

I am unable to reproduce the behavior in bash or csh as described by anandp@eng
in 4202425. Instead, csh -c uptime and bash -c uptime both run /usr/bin/uptime
even though /files/aecolley/local/bin precedes /usr/bin in my PATH and
I've mkdir'd /files/aecolley/local/bin/uptime. Consequently, I cannot reach
Anand's conclusion that fixing the bug would be counter-intuitive to Unix
users, but must support the opposite conclusion.

I agree that the Java runtime should not search the path itself; rather, it
should use execvp (in the Solaris build) to do the dirty work. However,
there is no execvpe function, so there is no alternative but to do the search.
The search semantics are well-defined (see Suggested Fix).

At the very least, the error message produced in fullPath() should instead
be produced in statExecutable, so that the error message contains the full
path of the failed pathname.