Jar依赖项编译时间和运行时

Question

If by default, when I produce a jar application, the dependencies are not include, does that mean that the user should download all the dependencies of my app to use it?

Why includes dependencies in jar is not the default thing?

How can I expect users to have/download all the dependencies at with the exact version needed?

Answer 1

From https://imagej.net/Uber-JAR :

Advantages :

A single JAR file is simpler to deploy. There is no chance of mismatched versions of multiple JAR files. It is easier to construct a Java classpath, since only a single JAR needs to be included.

Disadvantages :

Every time you need to update the version of the software, you must redeploy the entire uber-JAR (eg, ImageJ is ~68 MB as of May 2015). If you bundle individual JAR components, you need only update those that changed. This issue is of particular relevance to Java applications deployed via Java Web Start, since it automatically downloads the latest available version of each JAR dependency; in that case, your application startup time will suffer if you use the uber-JAR.

You cannot cherry-pick only the JARs containing the functionality you need, so your application's footprint may suffer from bloat.

If downstream code relies on any of the same dependencies which are embedded in an unshaded uber-jar, you may run into trouble (eg, NoSuchMethodError for unshaded uber-JARs) with multiple copies of those dependencies on your classpath, especially if you need to use a different version of that dependency than is bundled with the uber-JAR.

As you can see, it is important to understand how use of the uber-JAR will affect your application. In particular, Java applications will likely be better served using the individual component JARs, ideally managed using a dependency management platform such as Maven or Ivy. But for non-Java applications, the uber-JAR may be sufficient to your needs.

It basically depends on the use case. If the jar will be used in development of other applications and its dependencies might be updated time to time, it makes sense to use a normal jar, but if the jar is to be run/deployed, it might be better to use an uber/fat jar.