A suggestion - since Red Hat packages and distributes RHEL with Java RPMs from
IBM, and since jpackage-utils puts some nice reasonable defaults in
/etc/java/java.conf for Java variables, and since Red Hat now has a directory
server that uses Java for management, how about modifying startconsole to check
/etc/java/java.conf first?  :)

The following should hold true:
LIBJAVA_DIR=JAVA_LIBDIR
LIBJVM_DIR=JAVA_JVMDIR

The startconsole script didn't work for me to automatically detect
LIB{JAVA,JVM}_DIR, based on the output of find/sed, so I just hardcoded to the
above, which is what they would have ended up as anyway.  But after just digging
a little bit, the reason appears to be that "find /usr/lib/jvm/java -name
'libjvm.s[ol]'" returns nothing.

But:
cd $JAVA_HOME (or /usr/lib/jvm/java)
find . -name 'libjvm.s[ol]' returns ./bin/classic/libjvm.so

or probably better,

find $JAVA_HOME/ -name libjava\.s[ol]

works too, so I think the trailing slash after JAVA_HOME is needed.

> Sounds good.  Will this work on Fedora Core or other linux distros?

I'm not sure how portable it would be with other distros (it should definitely
work on FC), but here was what I was thinking:

Check /etc/java/java.conf and if it exists try using the values there.  Maybe
tickle to see if /etc/{redhat,fedora}-release exists first.  I'd vote for a
"assume nothing but the known distributions/environments where this works
approach" (which is to say that if say a /etc/java/java.conf file exists on a
Solaris install, don't blindly assume that the values in it are anywhere near or
even related to what exists in a Red Hat java.conf file).  For binary packages,
this probably means including a RPM dependency for jpackage-utils (which in and
of itself could still lead to problems, since you could have that installed but
have no JRE installed..).

The more ways there are to find where the JRE might be (which may amount to
figuring out what the clues are on each distro/OS), the lower the bar to entry
becomes and Things Just Work.