8 ms·
> 1. Runtime-linking _is_ dynamic linking, and it's a PITA that Java doesn't have an option for static linking, especially given the inherent fragility of the C
by gresrun 13y ago
> 1. Runtime-linking _is_ dynamic linking, and it's a PITA that Java doesn't have an option for static linking, especially given the inherent fragility of the CLASSPATH.
It is possible to roll a 'fat' JAR with all your dependencies baked-in, which is as close to static linking as it gets in Java-land. I prefer this for stand-alone applications as it makes deployment a cinch at the expense of the size of the build artifact.
- jebblue 13y agoAgreed, this is how I do my Java standalones. Eclipse makes this easy with Export | Runnable Jar providing several options for how to package the build.
- danieldk 13y agoThe Maven assembly plugin can also do this with the 'jar-with-dependencies' descriptor.
- gresrun 13y agoI personally use the maven-shade-plugin for this because it has built-in support for handling special resource files like licenses, service definitions, and manifest entries.
- agibsonccc 13y agoThe maven shade plugin can be dangerous if you hit the zip file limit of 65535 entries. Watch your filters.
- jonstewart 13y agoYeah, I've used jarjar before for this.
- yaeger 13y agoI wonder how such a setup would play out in regards to Open Source usage. Say you create a big jar with all dependencies in there in several layers of "lib" folders. Licenses like LGPL say you have to keep the LGPL archive accessible to the user and grant permission for them to alter/update them. Would a nested hierarchy of lib folders inside your jar be viewed as hindrance? Certainly you didn't "hide" the LGPL'd components in order for the user to not alter them but I think it could be viewed as "security through obscurity". If I don't immediately see a component, how do I know its there? I guess this could be solved by a readme that lists in detail what open source components are used and where in the hierarchy they can be found.