Launching JAM modules

[Michael Burton-4]

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.
_______________________________________________
modules-discuss mailing list
modules-discuss@...
http://mail.openjdk.java.net/mailman/listinfo/modules-discuss