3 ms·
In particular, if the use-case calls for all dependencies to be bundled together, then why not an uberjar? Why use something as wonky as Docker when the JVM eco
by lkrubner 8y ago
In particular, if the use-case calls for all dependencies to be bundled together, then why not an uberjar? Why use something as wonky as Docker when the JVM eco-system offers a solution that has been solid and mature for 15 years?
As to my use of "wonky", see some of the frustrations at the end of "Docker protects a programming paradigm that we should get rid of":
http://www.smashcompany.com/technology/docker-protects-a-programming-paradigm-that-we-should-get-rid-of http://www.smashcompany.com/technology/docker-protects-a-pro...
- random3 8y agoIt's about having a closer integration (i.e. beyond dropping a fat jar in a Docker) between the Java toolchain and Docker toolchain. Why? Because when you need to operationalize stuff, you suddenly or less suddenly and more painfully discover a tons of other concerns not directly tied to the actual Java build. Dependencies outside of uberjar (like JVM, glibc etc.), speed of builds (through incremental builds) and potentially size of the final artifact. This is a tool that helps with Docker images. If you don't need a Docker image, you clearly don't need it. If the question is why Docker images or why containers, then the answer is not in the docs for this tools.