[modules-discuss] Launching JAM modules
Michael Burton
mburton at niskala.org
Wed Nov 21 11:19:55 PST 2007
After being distracted with real life for a few months, I came back to http://openjdk.java.net/projects/modules/
and was impressed with the recent progress made on the modules
project.
This has motivated me to ask a question that's been on my mind for a
few major releases of java now. Have there been discussions
concerning alternate, perhaps more convenient mechanisms to launch JAM
(and jar) files? It appears that the currently supported mechanisms
use the "java -jam" launcher or a variant thereof, which is a very
consistent solution but has a couple of shortcomings.
Since java's inception, the burden has been on the user to know the
myriad of configuration necessary to launch a java jar file [1]. At a
minimum they must know which java to use - 1.4.2? 1.5? 1.6? [2]
Frequently though, they must also know what classpath to configure, or
what heap size to set, or what platform-specific properties the
application might require. It's because of this that most java
applications [3] ship with several platform-specific scripts to launch
the application. Most of these scripts go through exactly the same
contortions: find java, find the jar file, set the heap-size and some
OS-specific options, then launch the application.
This has always made java a second-class citizen on most OSs, at least
in my mind. Running a java application is not nearly as intuitive as
running a native application[4] for the typical user, but really it
could be.
With Modules, the requirement to set the classpath mostly goes away,
but things like heap size, java version, and java properties are still
very necessary.
There are probably various solutions to this problem, but one that
comes to mind is a simple descriptor packaged in the archive[5] which
could be read by a pre-java launcher that could launch the appropriate
version of java with the correct command line options [6]. Pair this
with platform-specific bindings (eg. using "#!/bin/javalauncher" for
POSIX [7], file type mappings for double-clicking on windows, mac,
KDE, etc) to associate JAM files with the launcher, and all of a
sudden we no longer need to ship launcher scripts with our java
applications.
Thanks
Michael Burton
[1] Or if not the user, then the packager must supply scripts that do
this for them.
[2] Or hope that their system default is compatible with the jar
application they're trying to run.
[3] Ant, maven, tomcat, jboss, intellij, to name a few that I use
frequently.
[4] Or even as running a simple shell/python/ruby script. Complex
multi-file scripts are another story.
[5] Perhaps the mainfest file?
[6] This is more or less the sort of thing that JNLP tackles on the web.
[7] It might be tempting to try to use "#!/bin/java -jam" instead of a
separate java launcher, but passing additional arguments like -jam to
the executable will not work on all UN*X variants, and the path to the
java executable is not standardized across environments.
More information about the modules-discuss
mailing list