[Link]Deliver Your Java Application in One-JAR!

greenflute

Delivering a runnable Java application is an exercise often frought with complexity and frustation. In principle, if you have a main class called com.mydomain.mypackage.Main, you can simply say:

      java com.mydomain.mypackage.Main       

However, this assumes that some magic has been applied to your shell environment to set the value of your CLASSPATH so that the java runtime can actually find this class. The CLASSPATH also has to contain all of the other classes which will be loaded and executed by your main program.

This is where things start to get much more complicated. Multiple entries on the CLASSPATH must be separated by a special character, and this special character is unfortunately operating system dependent (since it would otherwise interact badly with the common command shells). For example on UNIX it is ':', on DOS it is ';'. If these choices were reversed, the command shell on each operating system would become very confused. And there had better not be version any conflicts between entries on the CLASSPATH: the order of entries controls the order of class resolution, incompatible versions created by incorrect orderings will lead to obscure NoSuchMethodException exceptions and other runtime problems.

Wouldn't it be nice if you could just wrap up all your classes into one big executable, and run it? Well the Java2 Runtime Environment has a way of doing this using a JAR launcher. If you bundle your class, and all the supporting classes in a file called myapp.jar, and set the MANIFEST.MF appropriately, you can simply say:

      java -jar myapp.jar

Very nice. So what's the catch? There are numerous. One catch is that you must first unjar all of the supporting classes and flatten them out into a single directory tree before creating the final myapp.jar. For example: what happens if your application depends on some of the web-services JAR files from the Java Web Services Developer Pack? There are many of them and they all contain code which lives in the same packages (javax.*, com.sun.* etc).

Is this a problem? Well it may be. Consider that after you have expanded all of the code into a single tree, you have lost all trace of any code signatures that might have been present. Why? Because code signatures are located in /META-INF/MANIFEST.MF file, and each jar file will contain one of these manifest files, with different content. Likewise, any resources which have the same name (a distinct possibility given that the jar files themselves may contain flattened out packages) will be in conflict: you can only have one file called log4j.properties to control logging, where you might like to enable/disable logging on a boundary set by the individual jar files.

Wouldn't it be nice if you could just bundle the supporting jar-files into your myapp.jar file without expanding them? This is the problem addressed, and solved, by One-JAR.

http://one-jar.sourceforge.net/

asdfgh

麻烦楼主有空翻成中文吧，俺们不会外国话。:P:D