eclipse - What is the difference between runnable jar library handling options?

Question

So I will be using Java Web Start to deploy the java application. When exporting to a Runnable Jar, there are three options in eclipse Helios.

• Extract required libraries into JAR
• Package required libraries into JAR
• Copy required libraries into sub folder next to JAR.

What are differences, and how will they affect my .jnlp file?

If it's a single jar, isn't it easier because I wouldn't have to write all the different paths to all the libraries it uses?

If there are changes in both the library and the application, a single jar would be a better solution? Or would I need <jar href=''> for each individual libraries?

Also note that I need to make use of native libraries like .dll and .so files.

Answer 1

1. Extract required libraries into JAR - Extracts the actual .class files from the libraries your app uses and puts those .class files inside the runnable JAR. So, the runnable JAR will not only contain the .class files of your application, but also the .class files of all the libraries your application uses.

2. Package required libraries into JAR - Puts the actual JAR files of the libraries into your runnable JAR. Normally, a JAR file within a JAR file cannot be loaded by the JVM. But Eclipse adds special classes to the runnable JAR to make this possible.

3. Copy required libraries into sub folder next to JAR - Keeps the library JARs completely separate from the runnable JAR, so the runnable JAR will only contain the .class files of your application.

Option #2 is convenient because it packages everything neatly into a single JAR, and keeps the library JARs separated from your application's .class files.

However, a downside to packaging everything inside of a single JAR (options #1 and #2) is that, if you update your application, then the user will have to download more data to update the application. If the JARs are kept separate, then the user would only have to download the JAR that contains your application code, instead of a single, massive JAR that contains your application code and all the library code.