That's right. OSGi predated the Java Module system, and in many cases, informed its design. I think it's unfortunate that when they were including the Module system into Java, they didn't just import OSGi whole.

OSGi has an in-VM service registry which allows late binding of "services" by interface. This means you can do a lot of sophisticated mixing and matching of capabilities with OSGi, including the ability to load and use incompatible versions of the same library (if need be) in different parts of your code.

More than a decade ago, I built an app server system that used an OSGi base for server-side products and agent systems. I even had a flavor of JBoss running on OSGi (with dramatically faster start up times) before JBoss went OSGi on its own.

But now my teams do their work in Node. Isolation is by process, hopefully, maybe, and we're right smack back in version hell.

So many "modern" things in cloud are just relearning Java application servers (and .NET) by people that never used them.

> Java modules are doing alright since Java 9

Can you actually use them to use two different versions of library C in the same application yet though?

> Eclipse keeps using OSGi just fine

Wasn't the impression I had the last time I tried to fix a bug in an eclipse plugin that touched on the OSGi parts. The codebase felt like a ghost town and I couldn't find any documentation for how it all worked or anyone who knew about it.

> Can you actually use them to use two different versions of library C in the same application yet though?

Nope, this is functionality that Java (and thus, the module system) does not (yet) provide.