This package enables direct execution of Java applications, without the need
to explicitly invoke a Java interpreter. It relies upon the kernel module
binfmt_misc being available; this module is compiled if the
CONFIG_BINFMT_MISC option in the kernel configuration is set. Richard
Guenther, the author of binfmt_misc (and of the first version of
javawrapper), describes it like this:

> This Kernel feature allows you to invoke almost (for restrictions see
> below) every program by simply typing its name in the shell. This includes
> for example compiled Java(TM), Python or Emacs programs.
> 
> To achieve this you must tell binfmt_misc which interpreter has to be
> invoked with which binary. Binfmt_misc recognises the binary-type by
> matching some bytes at the beginning of the file with a magic byte
> sequence (masking out specified bits) you have supplied. Binfmt_misc can
> also recognise a filename extension aka '.com' or '.exe'.

javawrapper also depends upon a Java virtual machine being installed, and
expects you to have set up your CLASSPATH environment variable to point to
the system class libraries; the procedures for doing this should be
explained in your JVM documentation.

Once you have installed javawrapper, you should never need to run it
directly. Assuming you have a Java application in the file Test.class in the
current directory, you can just say:

  ./Test.class

and javawrapper will work out an appropriate CLASSPATH setting and run the
Java interpreter (which should be in /usr/bin/java) on that class.

In fact, if you want to make it less obvious that a program is a Java
application, you can create a symbolic link to it with any name you like.
javawrapper uses an auxiliary program called javaclassname to extract the
"real" class name - the one the Java interpreter expects you to use - and
traverses symlinks to find an appropriate directory to add to the CLASSPATH.
If it can't find a directory which could form the root of a package tree in
which to execute your class (the class foo.bar.Test ought to be in
Test.class in a directory foo/bar/ off the root, for instance), it will fail
with an error message describing the package tree it expects.

javawrapper is not a panacea. It will not create symbolic links for you in
an attempt to find a sane directory hierarchy for your class. It will not be
able to find classes your application depends on if they aren't in the same
package tree. It will not write your code for you. It should, however, be
able to hide some of the worse confusion caused by the filesystem layout
Java requires.

Please let me know if you have any suggestions on how to improve
javawrapper. Enjoy!

The newest version of this package may be obtained from
http://riva.ucam.org/~cjw44/javawrapper/.

