4 ms·
But for the case of deploying Java applications, it seems particularly redundant. The JVM already has a very extensive security manager framework, and since it
by chroem- 12y ago
But for the case of deploying Java applications, it seems particularly redundant. The JVM already has a very extensive security manager framework, and since it's Java it's already write once run everywhere. You can even easily bundle your entire project into a single executable .jar for deployment.
As a Java developer, I can't fathom why someone would want to add a redundant layer of cruft on top of their project. Docker may be the latest trendy thing, but it seems like many of its users aren't entirely sure why they need it.
Edit: I should clarify that I have nothing against hypervisors or other virtualization and sandboxing schemes. However, a lot of people seem to be running Docker, under an outside hypervisor, in order to run their also virtualized language runtime. That strikes me as a bit pointless.
- diltonm 12y agoIt's the daemonizing part that complicates things. Running java -jar MyApp.jar is easy, running it under the control of a system init script, dealing with how to ensure it's restartable as other daemons, logging, log rotation, where Java is really located on the system are all variables that affect any daemonized application; not just Java apps but ones written in any language, Ruby, Python, C or C++. Docker seems like a good way to "contain" the problem domain challenges I outlined, hoping anyway.