1. It assumes /usr/bin/java is a shell script, and that /bin/bash exists
to execute it. If /usr/bin/java is an executable or if /bin/bash
does not exist, it will fail.
2. The code to strip ".class" from the filename is incorrect. It will
truncate "/usr/tom/my.classes/spud.class" to "/usr/tom/my".
3. It throws away the directory of the file attempting to be executed,
expecting the java interpreter to find it in some magic list
of paths which is distinct from the PATH environment variable the
shell used to find the executable in the first place.
I have patched binfmt_java.c to fix all of this, but I have a question
about point 3. I downloaded the kaffe java interpreter from the Jolt
project to see how the class to be executed was specified. It turns
out that it takes an argument which is a class name, not a file name,
then it looks up the file in some built-in path like I mentioned in
point 3. Although this is what binfmt_java.c expects, it does not
seem like a good policy since the java code that gets executed may not
be what you expect by doing "whence progname".
Do other java interpreters, e.g. the one in Sun's JDK, work this way?
(Distribution of the Linux version of the JDK is on hold, and I don't
really feel like downloading Sun's source to get the answer.) If so,
perhaps the best solution would be to make /usr/bin/java a shell
script, pass it the complete filename as $1, and have it generate the
appropriate arguments for whatever java interpreter you have
installed. For example, a /usr/bin/java that supported kaffe might
look something like this:
#! /bin/sh
/usr/local/bin/kaffe -classpath `dirname $1` `basename $1 .class` "$@"
This would cause kaffe to load the class from the directory where the
shell tried to exec it from in the first place.
Comments, especially from the original author of binfmt_java.c, would
be appreciated.
Tom.