> We avoid the fanfare of Docker, as really it's not needed for Java apps; they're somewhat self-contained anyway and it created more problems than it solved.
What does this mean?
What does this mean?
For example, if you're writing code in C++ targeting Linux, using Docker helps with reproducible builds and deploying on any hardware.
But if you have a VM, there are less advantages. There still are some, of course, with orchestration etc if you want it.
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.