* Every time you need to update the version of the software, you must redeploy the entire uber-JAR (e.g., [[ImageJ]] is ~
57 MB as of June 2014). If you bundle individual JAR components, you need only update those that changed. This issue is of particular relevant 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 (e.g., <code>NoSuchMethodError</code> 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.