This one comes from two different customer bug reports:

fp.bugs 3317 ###@###.### (Robert Goldberg)
:
The .java_wrapper file distributed with the 1.0 release (and all Java
releases since alpha) does not work if you define your $JAVA_HOME
environment variable to be something other than ".", e.g., if you
define it to point to your bin directory.

Diagnosis:

.java_wrapper carefully sets up a temporary variable $J_HOME to be
the current directory and then sets $JAVA_HOME to this temporary
variable only if it is not already set. But the rest of the script
merrily uses $J_HOME, ignoring the now correctly set $JAVA_HOME.


fp.bugs 3281: >From: ###@###.### (Dan Zigmond)
Basically, I think this script is figuring out the Java "home" incorrectly. It
only causes problems when you set up the JDK using links (as we do here), so
that, say, /usr/local/bin/javac is set up to point to something like
/usr/java/bin/javac. Here are the first few lines of the script (w/o comments):


(1) PRG=`whence $0` >/dev/null 2>&1
(2) J_HOME=`dirname $PRG`/..

(3) if [ -z "$JAVA_HOME" ] ; then
(4) export JAVA_HOME
(5) JAVA_HOME=$J_HOME
(6) fi

(7) CLASSPATH="${CLASSPATH-.}"
(8) if [ -z "${CLASSPATH}" ] ; then
(9) CLASSPATH="$J_HOME/classes:$J_HOME/lib/classes.zip"
(10) else
(11) CLASSPATH="$CLASSPATH:$J_HOME/classes:$J_HOME/lib/classes.zip"
(12) fi
(13) export CLASSPATH

As you can see, lines 1 and 2 make a tentative guess at where Java is stored in
the filesystem and store this in J_HOME. This guess will be wrong in the
linking scenrio I explained above, but it's still probably right more often than
wrong. Line 3 then checks to see if the JAVA_HOME variable has been set; if
not, then our guess from line 2 is our only hope as JAVA_HOME is set to J_HOME.

Now, in my opinion, all references to J_HOME in the rest of the script should be
changed to JAVA_HOME. This allows the user to override the guess made in the
first two lines with the correct location of Java in the filesystem. The way
the script now readys, lines 9 and 12 will set CLASSPATH incorrectly when the
J_HOME guess was wrong (because of links). If JAVA_HOME was used instead of
J_HOME, CLASSPTH would always be set correctly, because by this point in the
script JAV_HOME is guaranteed to be either set by the user or set by the script.

This "bug" actually causes the script not to work at all in our environment,
because further down .java_wrapper tries to construct the program name to
execute using the lines:

progname=`basename $0`
prog=$JAVA_HOME/bin/`uname -p`/${progname}

This logic just doesn't work in the case where links have been used so that
J_HOME is incorrect bu JAVA_HOME is correct. The attempt to exec prog always
fails.

I've been manually fixing this by changing the J_HOME references after line 6 to
JAVA_HOME. Is there any reason for you not to just do this in your released
script? Am I missing something that causes J_HOME to be the correct variable to
use here?