Solaris fix was ported to Linux.

(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  xxxxx@xxxxx  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  xxxxx@xxxxx 
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.

Use only absolute paths to the command in Runtime.exec().

I agree that we should skip directories.  See comments for what went
wrong in my evaluation of 4202425.

 xxxxx@xxxxx  1999-05-19


 xxxxx@xxxxx  2001-07-25
Currently (JDK1.4 beta) this appears to be fixed in the Solaris version


We need to port Solaris fix to Linux

 xxxxx@xxxxx  2001-09-11

I had the same problem with JVM 1.2.2.0.3, HotSpot edition 
under HP-UX 11. Having "/opt/netscape" (with a java dir 
inside) in the PATH before the "real" Java JDK pathname, 
caused a "java.io.IOException: java: cannot
 execute" error.
To solve the problem we had to modify the PATH variable.

I'm getting this problem on windows XP running from 
ant with Java 1.4.2_01.

At a guess I'd say it is due to the input path length. I 
have a large classpath. The command ends with a ? 
where it truncates the input from the ant task.

I have the same problem with runing ant through eclipse 3.0.1.