OSGi vs. Jigsaw: Kirk Knoernschild on Modularity

Kirk Knoernschild is one of the leading experts when it comes to the OSGi community.  DZone recently had a chance ot interview him about his thoughts on modularity in 2012 and his new book is "Java Application Architecture: Modularity Patterns with Examples Using OSGi." The book introduces 18 patterns that will help you design more modular software.

DZone: Who is your target audience for the book? Is it more than just developers using OSGi?

Kirk Knoernschild: The book is for any software developer or architect who wants to build more architecturally resilient software. Quite frankly, I hope that's just about everyone who creates software for a living. Since OSGi is a module framework, I decided to include a few examples that use OSGi. But there are many more examples that do not use OSGi and these examples demonstrate how we can begin building modular software right now, even if you're not using a module framework like OSGi. And even though the examples all use Java, it's pretty easy to imagine how they are equally applicable to other platforms, like .NET.

What's really interesting about this is when you start to compare and contrast the different examples, it's pretty easy to see the benefits of a module framework like OSGi. The first example of this appears at the end of Chapter 3. Then, in Part 3 toward the end of the book, I take several of the pattern examples and "OSGi-ify" them. Because the samples used the patterns, they are already highly modular and introducing OSGi into the mix is very easy. So in addition to helping you design modular software right now even though you aren't using a framework like OSGi, the book also helps prepare you for the transition to a module framework when platform support is available. And platform support for modularity is coming soon, be it OSGi or Jigsaw, so this book helps your prepare for that support and design better software in the process.

By the way, I just uploaded an excerpt from the book to the book's website, which includes Chapter 3, so you can see what I'm talking about when I say that it's pretty easy to see the benefits of a module framework.

DZone: What are the benefits of modularity and why is it so important?

Kirk: Well, there are several subtle benefits, and this is really the focus of the first seven chapters of the book where I talk about why modularity is so important. Modular software is much easier to extend, reuse, maintain, and adapt. It's much easier to understand the ripple affect of change, so you know exactly what's going to be affected when you change a piece of code that has a lot of incoming dependencies. In the grand scheme, it helps you increase development agility because it's much easier to respond to change, knowing what the impact of change is going to be. These are real benefits that you experience almost immediately.
But I guess fundamentally, it's not imperative that you design software this way today. I mean, face it, we've been designing software without modularity for a very long time. So even though modularity helps a lot, we can certainly just keep doing what we've always done and design these huge monolithic applications. Perhaps what's more interesting is what looms on the horizon. The days of designing these monolithic applications must come to and end. In fact, it will come to and end and we see it happening right now.

The days of the tiered application architecture, where you design a presentation tier, functional tier, integration tier, etc and then package it all up into an application isn't going to work anymore because we live in a multichannel world today. It's just not feasible to design different applications for the desktop, mobile web, native mobile, etc. Instead, we have to start delivering Web APIs that allow you to support many different clients. Services are a good starting point, but aren't quite enough. As I like to say, within each service awaits a rotting design and without modularity, your services become these huge monoliths too. So you have to architect all the way down, and modularity helps you do this. Modularity is a cornerstone of the future architectural model and we have to start designing modular software. Major platform vendors are recognizing this. The OpenJDK recognizes this. And we, the enterprise developers, have to recognize this too.

The book shows you how to do this today. Then, once your platform actually treats modularity as a first class construct, several other amazing things begin to happen. You're no longer building applications, but instead are creating additional capabilities that, once deployed, simply extend the functionality of your environment. The environment itself responds to these capabilities and does what it needs to enable them. Again, I talk about these ideas in the first seven chapters and then show you how to do it in the remainder of the book. There are several examples of this taking place already today, though in a more limited fashion. The most obvious is the Eclipse platform, of which the plugin model is based entirely on modularity. Another is IBM's recent Liberty Profile. In this latter example, the local environment responds to the requirements of the application and provides just the right set of capabilities. It's pretty cool stuff. Just about every platform vendor is incorporating ideas like this into their platforms, and most are using OSGi to do it. Other vendors, like Paremus, are leading the change by introducing new platforms. And as we look to move applications to the cloud, this type of dynamic platform is a perfect fit. Kind of makes the this concept of Profiles that were introduced as part of Java EE6 look pretty antiquated because they are still so static.

DZone: A module framework like OSGi is one way to design modular software for Java.  Java 8's Jigsaw will be another.  Are there any other ways for Java?  For other languages?

Kirk: Well, certainly there is the way that my book promotes, which allows you to start designing modular software right now, even if you're not using a module framework like OSGi or Jigsaw. Isn't three ways enough? :-) I guess what's most important is that there is compatibility between each of these ways. One thing I was really careful to ensure with the book is that you can use the patterns even if you're not using a module framework. That's really important to stress. The patterns help you design modular software right now and the patterns also help you get ready for the transition to OSGi or Jigsaw when it's available in Java 8.

When it comes to other languages, the ideas in the book translate quite well. It's pretty easy to see how the patterns discussed in the book would translate to the .NET platform. It'd be nice to build some momentum here and start translating the examples to C# actually. And the patterns are largely language agnostic. For instance, in Part 3, I show how easy it is to use a language like Groovy and Scala. The result is pretty amazing actually because modularity hides the implementation details so well that it's entirely seamless.

DZone: What is your personal Pros and Cons list for OSGi vs. Jigsaw?

Kirk: The biggest advantage of OSGi is that it exists today and it's a proven module framework. Jigsaw, on the other hand, is still under development and won't be available until Java 8 is released, probably sometime in 2013. Jigsaw's biggest advantage is that it's going to be baked right into the Java 8 platform. It'll be part of Java SE.
I don't really want to get into the tension that exists between the OSGi and Jigsaw community. There is certainly disagreement over some key items, but the reality is that both OSGi and Jigsaw are going to be major components on the Java platform and developers are going to have to choose one based on their needs. I've heard some folks in the OSGi community say that OSGi is what a module framework looks like after it's grown up. So what they're really saying is that if Jigsaw is done right, it'll eventually become OSGi. We'll have to wait and see. What's most important here is that the two models are compatible, and we've been promised that they will be. It'd be a shame if Jigsaw modules couldn't run alongside OSGi modules because that's just letting a political squabble get in the way and the people it's going to hurt most is developers.
I'm not sure if I've mentioned this yet (ha!), but the patterns in the book are agnostic to a specific module framework. You can use them with OSGi, Jigsaw, or on the Java platform today. So if you start designing software this way, you are effectively future proofing the architecture so that you can adopt the module framework you want when you want to.

DZone: How widespread is OSGi in the Java community and what are your predictions for how adoption will change based on the introduction of Jigsaw?

Kirk: Fascinating question. Just about every software developer is an OSGi consumer today because just about every platform and every IDE use OSGi. The major platform vendors, including IBM, Oracle, and Red Hat are all using OSGi to build up their platforms. What's interesting is that OSGi hasn't penetrated the enterprise developer space yet. At least, it hasn't gone mainstream yet. Some people might complain that OSGi is too complex. But what they're really saying is that designing modular software is really really hard. Because it is.

I always like to say that if it's good for the goose, it's good for the gander. That is, if the platform vendors are using OSGi as the cornerstone of their platforms, then maybe we should think about using it for the applications we build. These platform guys are some pretty smart technologists, and if they think it's really that important, maybe we should take note. And it's not just OSGi, but modularity in general. Obviously Oracle thinks modularity is pretty important since they're investing in Jigsaw. These huge monoliths, like Java's rt.jar, just aren't going to cut it anymore.

At this point, I really can't say which is going to win over the hearts of the development community. OSGi is mature and proven, but Jigsaw is going to be the standard. The next couple of years will be an interesting ride for the Java platform, and a lot of things are going to change. My intent with the book is to help you incorporate modular design thinking into your development initiatives today.