Java apps have been "cloud ready" in a sense for about 20 years. JavaEE had a "WAR" or web archive file format that packaged an entire app up into a single file that could be deployed in an "Web Application Server". IBM wanted web servers to be mainframes, but for webapps. You could even deploy multiple apps in a single JVM, because the server would load each app in a separate classloader, meaning the apps were internally isolated from each other. The JVM even had an attempt at a cgroups like concept, called a Security Manager (that was abandoned, thank goodness), long before cgroups existed. Think WAR file = docker container.
Now, a lot of complicated bits were inherited that didn't need to be there when they brought over the mainframe thinking into Java apps, but the WAR format was actually something kind of cool they got right.
We in particular, take that WAR format, turn it into an executable, and we have a program that can execute on any hardware on any person's computer, with no pre-reqs except a JVM being installed. We test the _exact_ war file on a ARM RPI , developed on a Mac m1 or x86, and CI on a Linux x86.
Alright what does this mean? Lets take a look at another language...say a PHP application.... which may require extension Unix utilities of certain versions installed on the host system. You may need a certain version of PCRE grep, a certain version of curl, etc. This theme carries over to multiple languages, your python or ruby implementation may not support the latest version of libressl, or it might not even support your ABI at all. Docker solves these problems gracefully, by providing a fully configured virtual operating system tuned for running exactly one app.
The JVM... well doesn't need that, if written properly. Generally all the libs it uses are written in Java, they include all of their dependencies already, apps can be isolated with classloader boundaries (if that's your thing), you can download a single file and launch it if you use the "one-jar" technique.
So yeah, Docker loses a lot of it's luster with Java. It's not that you _cant_ use it, but it you can solve all the problems it does otherwise. Long rambling explanation but there you go.
Now, a lot of complicated bits were inherited that didn't need to be there when they brought over the mainframe thinking into Java apps, but the WAR format was actually something kind of cool they got right.
We in particular, take that WAR format, turn it into an executable, and we have a program that can execute on any hardware on any person's computer, with no pre-reqs except a JVM being installed. We test the _exact_ war file on a ARM RPI , developed on a Mac m1 or x86, and CI on a Linux x86.
Alright what does this mean? Lets take a look at another language...say a PHP application.... which may require extension Unix utilities of certain versions installed on the host system. You may need a certain version of PCRE grep, a certain version of curl, etc. This theme carries over to multiple languages, your python or ruby implementation may not support the latest version of libressl, or it might not even support your ABI at all. Docker solves these problems gracefully, by providing a fully configured virtual operating system tuned for running exactly one app.
The JVM... well doesn't need that, if written properly. Generally all the libs it uses are written in Java, they include all of their dependencies already, apps can be isolated with classloader boundaries (if that's your thing), you can download a single file and launch it if you use the "one-jar" technique.
So yeah, Docker loses a lot of it's luster with Java. It's not that you _cant_ use it, but it you can solve all the problems it does otherwise. Long rambling explanation but there you go.