Sometimes, java -version:xxx fails because it has misconstructed the path to the java. This caused our application to fail, but the user isolated it down to the java failing without our application being involved:

http://forum.java.sun.com/thread.jspa?threadID=5209110&tstart=0

# java -version:1.5+
Unable to resolve /usr/jdk/jdk1.5.0_12

The directory /usr/jdk/jdk1.5.0_12 does exist, the problem is a garbage byte with value 0x1 inserted after /usr/jdk. The output of

# truss java -version:1.5+

ends with:

access("/usr/jdk/jdk1.5.0_12/bin/java", X_OK) = 0
getdents64(3, 0xCE7A4000, 8192) = 0
close(3) = 0
resolvepath("/usr/jdk/jdk1.5.0_12", 0x08046F64, 1024) Err#2 ENOENT
fstat64(2, 0x08046200) = 0
Unable to resolve write(2, " U n a b l e t o r e".., 18) = 18
/usr/jdk/jdk1.5.0_12write(2, " / u s r / j d k01 / j d".., 21) = 21

write(2, "\n", 1) = 1
mmap(0x00000000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xCE680000
_exit(1)

Note the reason the resolvepath() call fails is that the "/usr/jdk/jdk1.5.0_12" argument has a garbage 0x1 byte inserted after "/usr/jdk", as I verified by looking at the output in a hex editor.
Notes:

The systems involved are x86. We haven't been able to duplicate the problem in-house.

/usr/jdk/latest points at a 1.5.0_12:

% /usr/jdk/latest/bin/java -version
java version "1.5.0_12"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing)