Jigsaw vs. OSGi?

It’s been awhile, and things have changed again. JSR 277 is dead. JSR 294 is alive and well. IBM almost bought Sun. Oracle actually did. And Jigsaw is on the horizon and appears to be on a collision course with OSGi.

The multi-module-verse. Like the parallel universes idea, Sun’s introduction of Jigsaw seems to create a significant fork in Java, with OSGi bundles in one version of reality and Jigsaw modules in another, forever isolated. Which begs the question: which reality do you want to inhabit? Better decide fast and jump the right way; the future of your code may depend on it.

Are we really going to be forced to choose? The answer is unfortunately yes, as things stand today. Each module system has its own model for deploying, loading and resolving dependencies across classes, and they won’t know how to share. So if you package your classes in a Jigsaw module, but want to use classes packaged as an OSGi bundle, you’re SOL. And the same is true in reverse. Heavy sigh.

As Neil Bartlett pointed out, one solution to this problem could be an acquisition that simply kills off Jigsaw, replacing it with OSGi. And sure enough, an acquisition has been announced.

But it would be a mistake to jump to any conclusions at this point on the future of Jigsaw.

Not only is it way too soon, it is also not as clear a choice as some would have you believe: Sun does have some valid reasons for building a simple module system for the JRE itself.

Where things get really contentious is when that same module system becomes the default choice for all developers. And the “our way is right/we know better” arguments flare up. But there is no “right” way—as with most software, different situations require different trade-offs.

Of course, we do have a standard model for solving this problem: a common API that enables different implementations. And we should use it here.

I won’t predict the life expectancy of Jigsaw, but one thing is crystal clear to me: the Java platform needs an abstraction layer for module systems. One that makes it possible for different implementations to exist, simultaneously and/or over time. One that provides a meaningful way for those implementations to share classes, so developers are not forced to make a potentially risky commitment. And one where a JVM vendor, or anyone else, can craft an optimized solution without shattering the universe.

Even if we could all agree on a single module system, an abstraction layer is still the right thing to do to help future proof the platform that so many of us depend on. It's just good software engineering.

If there is anything I'm sure that we should kill, it's the "us versus them" divisiveness that has dominated this space for so long.