It kind of does: Jave EE was all about having single Java Application Servers running on each host, and deploying applications/services on top. In practice every service was built by the same company though, so focused moved toward shared libraries in containers and things like that: Search for OSGI.

The issue is both that the security concerns were way softer than they are today, and that all your dependencies better be deplorable in a JVM too. Modern ideas of having databases deployed along with the services that need them don't work quite as well as just using OS level virtualization. That said many a crufry old company still deploys hundreds of services to production by loading .war files into a cluster of servers running JBoss or WebLogic.

> and that all your dependencies better be deplorable in a JVM too.

Remember: Never use the standard library when a forgotten, half-assed CPAN module you can run via Perlito will kind of do.

> your dependencies better be deplorable in a JVM too

Sadly, many Java dependencies are quite deplorable.

You are effectively correct, and to take it a bit further the "VM" in JVM does mean the same thing as the VM in VMWare even if it feels a lot different in practice. If all your dependencies are JVM based and bundled into a JAR/WAR, OS containers aren't doing much for you.

They're doing a ton for your CV though.

The JVM is a container by itself, and it has been able to isolate dependencies and memory requirements for many years before docker was conceived. The JVM doesn't do everything that docker does, for example it doesn't provide overlay file systems, but this is trivial to add via standard tools (e.g. aufs), and it also doesn't limit CPU usage per container but this is also trivial to add without having to deal with the extra complications of using docker. I think docker is great for non-JVM applications that run into conflicts with other applications, dependency-wise or resource-wise, but I don't see the point of using docker for pure Java applications. It just adds an unnecessary layer that provides no benefit.

Edit: If the point is to encapsulate and isolate a Java application as much as possible, I would consider using a unikernel like OSv before considering Docker. This would be more efficient and also more secure.

Yes, but some JVM implemetations have(had?) more support for this use case than others:

e.g. https://www.ibm.com/developerworks/library/j-multitenant-jav...

It is perhaps doable by getting very intimate with Java's classloaders and security policies, but most people don't want to deal with that stuff--it's complex, not fun, not portable.

That said, there are practical examples to be found in common servlet containers, with some shared libraries, but individual servlets mostly firewalled from each other.

Servlet containers have two levels of isolation: individual apps are mostly firewalled from each other as you say, but when running multiple servlet containers they are as isolated from each other as multiple docker processes are when it comes to shared libraries, security policies etc. JVM processes are easy to reason about at the OS level, while servlet applications are more complex. But we are comparing Docker with JVM, not Docker with e.g. Tomcat webapps.

Sorta. The JVM provides portability but has less fine controls for things like disk, network and CPU isolation and limiting.

This got me thinking about how it is on Clojure, and turns out there's a library for doing that: https://github.com/RutledgePaulV/clj-embed

No more so than any other language with a VM, which typically isn't much at all.

The PR for memory protected preemotive multitasking operating systems still sounds remarkably similar to the container sale pitch today (at least the first half of it).

I wonder what we’ll be championing in another 10 years.