OSGi, Java Modularity and Jigsaw

First understand that Jigsaw's primary use case is to modularise the JRE itself. As a secondary goal it will offer a module system that may be used by other Java libraries and applications.

My position is that something like Jigsaw is probably necessary for the JRE only, but that it will create far more problems than it claims to solve if used by other Java libraries or apps.

The JRE is a very difficult and special case. It is over 12 years old and is a frightful mess, riddled with dependency cycles and nonsensical dependencies. At the same time is is used by approximately 9 million developers and probably billions of running systems. Therefore you absolutely cannot refactor the JRE if that refactoring creates breaking changes.

OSGi is a module system that helps you (or even forces you to) create software that is modular. You cannot simply sprinkle modularity on top of an existing non-modular codebase. Making a non-modular codebase into a modular one inevitably requires some refactoring: moving classes into the correct package, replacing direct instantiation with the use of decoupled services, and so on.

This makes it hard to apply OSGi directly to the JRE codebase, yet we still have a requirement to split the JRE into separate pieces or "modules" so that cut-down versions of the JRE can be delivered.

I therefore regard Jigsaw as a kind of "extreme measure" to keep the JRE code alive while splitting it up. It does not help code to become more modular, and I'm convinced that it will actually increase the maintenance required to evolve any library or application that uses it.

Finally: OSGi exists whereas Jigsaw does not exist yet and may never exist. The OSGi community has 12 years of experience in developing modular applications. If you are seriously interested in developing modular applications, OSGi is the only game in town.

It's simple, if you want to do real component-based development in Java today then OSGi is the only game in town.

In my opinion, Jigsaw is a combination of a compromise of what's doable in the JDK and previous bad relationship between SUN and the OSGi guys. Maybe it will ship with Java 8, but we have to wait and see.

OSGi is no panacea if you are working in a typical enterprise setting and you will need to become familiar with how class loading works as a number of well-known libraries (looking at you, Hibernate) made assumptions about class visibility that are no longer valid inside OSGi.

I like OSGi, but I wouldn't try and retrofit it to an existing system. I'd also weigh the pros and cons in terms of greenfield development - I would recommend looking at the Apache or Eclipse products that simplify life for OSGi and not doing it all yourself.

If you're not doing OSGi, then your out of luck if you've come up with a system that has dependencies on different versions of the same library - all you can do is try and avoid the problem, though needing multiple versions of a library seems like a architecture 'smell' to me.

I love your use of the phrase "corner cases" to describe the current situation.

there are shortcomings with the JAR file specification that can lead to namespace resolution and classloading issues in certain corner cases

Anyhow, since many years I've been interested in tools and techniques that supports the creation of and, even better, enforce, code that is cleaner, more decoupled, more coherent and more maintainable than what probably would have been the result without them. Test Driven Design and Junit was such a combination.

After having spent a couple of months moving a substantial part of our code base to OSGi, I would say that OSGi is an even better tool in this regard. And that is really a sufficient reason to move to OSGi. In the long run it will save you a lot of money.

And, as a bonus, it'll give you a chance to do a lot of cool stuff. Imagine, during a demo, seamlessly upgrading the authentication module, without traffic loss, to support OAuth ... it's suddenly a joy again to create stuff!