Advantages/disadvantages of building one huge jar

Question

I have seen programs like http://one-jar.sourceforge.net/ and http://fjep.sourceforge.net/index.html promote rolling your application jar and any dependencies into a single, executable jar.

What are the main reasons for/against doing this?

Answer 1

One legitimate reason that I've seen in the workplace is due to the fact that a vendor provides hotfix jars that need to precede the original version in the classpath.
However, this application is launched via java webstart (jnlp) and as of java version 6, the order of the jar file dependencies is no longer guaranteed.
Therefore the only way to ensure that the duplicated class files are in the correct sequence is to re-package them into an uber jar, retaining the latest patched class files and discarding older duplicates.

Answer 2

For:

• easier distribution,
• makes classpath problem go away,
• can be packaged even in Ms PowerPoint presentation as a clickable icon, probably OpenOffice also can handle it.

Against:

• difficult packaging - sometimes you hit a corner case such as: how to package native extensions,
• requires extra build step,
• generates larger jars,
• can violate library's license agreement,
• kills the notion of library reuse,
• makes updates and
• debugging (because of extra classpath loader) more difficult.

So generally, it's really a great way for quick prototyping, but can get in a way if used in a bigger project.

Answer 3

Redistribution licenses applicable to dependencies is one major reason against building a "uber" jar. When one creates a "uber" jar, distribution of any dependencies occurs, via distribution of the "uber" jar. And in regions, where case laws do not cover this scenario adequately, one might open themselves up for liability.

Additionally, some commercially obtained dependencies might prohibit repackaging of dependencies, especially if the original distribution is not conserved.

PS: This is not legal advice. Anyone reading this and depending on this for undertaking business decisions, should be consulting a lawyer.

Answer 4

Distribution FTW! It's so much easier on the user rolled up in to one.

Answer 5

For:

• Bundling of libraries and native code
• Ensure proper runtime ordering of classpath elements
• Remove need for installers

Against:

• New top level classloader may introduce issues not seen during normal development cycle
• Legality of re-packaging libraries under disparate license terms

In general, if it is a small utility application, I will bundle it into a single jar. For larger applications (which likely will require an installer anyway), or if it is a library for others to use, I will not bother. It will be just another link in the chain of things that can break.