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.
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.
Nope, this is functionality that Java (and thus, the module system) does not (yet) provide.
You are correct. As of now, Java Modules have no way to disambiguate versions of the same dependency. This is intentional and by design.
As far as Java is concerned, each class is uniquely identified by ModuleName.PackageName.ClassName. So, if there are 2 versions of the same class that have the same identifier, Java will give you an error at compile/link/run-time.
And if you try to be clever and slap a number at the end of the module name (in hopes of side-stepping this), Java will throw a warning at you, saying that you are likely trying to misuse modules by trying to use them to do dependency management.
OSGi is the one that's deprecated and Java Modules is the one that can't actually provide that functionality yet, right? Or is it the other way round? Either way you get the point.