<p>I am new to Docker and been reading a lot about it. But when I look at it from Java application perspective, I am not sure what value addition it does in terms of 'packaging dependencies' which is one of the important factor called out in their documentation.</p>
<p>Java is already a language which can run on multiple OS using the JVM layer abstraction.Build once , run anywhere is not new concept. Docker container do allow me to ship my JRE version along  with my application code. So I see that benefit,  but is there any other benefit I get, especially when my environments( host environments) aren't going to change. i.e I will be using Linux boxes for deployments.</p>
<p>A fat jar file is as good as a packaging can get to bundle all the dependencies using maven build. I understand that containers really help with deploying on the platforms like Kubernetes, but if I have to strictly judge containers in terms of packaging issue, isn't jar package enough? I may have to still containerize it to benefit from running light weight processes instead of running them on VMs.</p>
<p>Does the JRE layer gets reused in all other containers ? This would be akin to installing the JRE on my VM boxes. All apps on the box will use the same JRE version. Unless, I need to run diff versions of JRE for my application which is highly unlikely.</p>

Metalhead
<p>If you have a working deployment system using established technologies, you should absolutely keep using it, even if there is something newer and shinier.  The Java app server space is very mature and established, and if you have a pure-JVM application and a working setup, there's nothing wrong with staying on that setup even if Docker containers exist now.</p>
<p>As you note, a Docker image contains a JVM, and an application server, and library dependencies, and the application.  If you have multiple images, they're layered correctly, and these details match <em>exactly</em> then they could be shared, but there's also a very real possibility that one image has a slightly newer patch release of a JVM or the base Linux distribution than another.  In general I'd say the Docker ecosystem broadly assumes that applications using &quot;only&quot; tens of megabytes of disk or memory aren't significant overhead; this is a major difference from the classic Java ecosystem where multiple applications would run on a single shared JVM inside a single process.</p>
<pre class="lang-sh prettyprint-override"><code># This base image will be shared between derived images; _if_ the
# version/build matches exactly
FROM tomcat:10-jdk11

# These libraries will be shared between derived images; _if_ the
# _exact_ set of files match _exactly_, and Tomcat is also shared
COPY target/libs/*.jar /usr/local/tomcat/lib

# This jar file presumably won't be shared
COPY target/myapp.jar /usr/local/tomcat/webapps
</code></pre>
<p>I'd start looking into containers if you had a need to also incorporate non-JVM services into your overall system.  If you have a Java component, and a Node component, and a Python component, and they all communicate over HTTP, then Docker will make them also all deploy the same way and it won't really matter which pieces are in which languages.  Trying to stay within the JVM ecosystem (and maybe using JVM-based language implementations like JRuby or Jython, if JVM-native languages like Java/Kotlin/Groovy/Scala don't meet your needs) makes sense the way you've described your current setup.</p>
