Kirk is a software developer who has filled most roles on the software developer team. He is the author of Java Design: Objects, UML, and Process (Addison-Wesley, 2002) and he contributed to No Fluff Just Stuff 2006 Anthology (Pragmatic Bookshelf, 2006). His most recent book, Java Application Architecture: Modularity Patterns with Examples Using OSGi was published in 2012. Kirk is a DZone Zone Leader and has posted 77 posts at DZone. You can read more from them at their website. View Full User Profile

A New Year’s Declaration

  • submit to reddit

2010 is going to be a big year for modularity on the Java platform. So based on recent industry trends, and as momentum continues to build around modularity on the Java platform:

I hereby officially declare 2010 as the year of modularity on the Java platform.

So that’s a relatively silly statement, and I really don’t have any authority to make such sweeping declarations. But the statement is backed by some pretty serious trends. Here are a few nuggets to chew on that has led me to believe modularity is going to be bigger in 2010 than ever before!

Between 2007 and 2009, we saw amazing momentum build around OSGi. GlassFish, Jetty, Spring DM, SpringSource dm Server, Paremus Infiniflow, Nimble, PAX, Sigil, Aries, WebSphere, JBoss, Maven, and of course Eclipse are just a few products that leverage OSGi. The list goes on. The number of 3rd party frameworks that have been “osgi-ified” has also grown substantially. And whether you love it or hate it, let’s not forget about Jigsaw and JSR-294.

But there has been a nagging problem…an elephant in the room you might say…that’s hindered widespread adoption. Without gluing together a platform, assembling it yourself, or adopting an entirely new platform, aside from the vendors who were already exposing the virtues of OSGi in their products, the majority of enterprise developers were unable to leverage any of it to build modular enterprise applications! But in 2010, that’s all going to change.

Modularity is coming to the enterprise and you’re going to be able to use it to build modular applications. IBM has already made this announcement. I suspect others will follow suit. For those using SpringSource dm Server or Infiniflow, you’re probably already doing it. With the major platform vendors showing their support for a technology that’s already embedded in products such as dm Server and Infiniflow, I suspect these platforms will see an increase in market penetration through 2010 and beyond. And I suspect you can expect some big announcements surrounding these products soon. Finally, let’s not forget, if it can avoid another delay, JDK 7 (with support for modularity) will be released in September.

Whereas prior to 2010, enterprise developers could only dream about building modular applications (or work very hard to do so), modularity is going to take center stage. And since modularity lies at the heart of the platform, it doesn’t matter what language you use. Neil showed us how to do it with Scala way back in 2007. And Groovy does OSGi, as does Clojure. Yep, so does Scala. So no matter which language you use, you’ll be able to take advantage of modularity on the Java platform.

In 2010 modularity on the Java platform is going to be a game changer…a disruptor…that reaches from the developer to the data center. As 2010 progresses, more and more developers will be touched by modularity. It’s not something we should ignore. Really, it’s not something we can ignore anymore.


Published at DZone with permission of its author, Kirk Knoernschild.


Fab Mars replied on Wed, 2010/01/06 - 7:51am

...That was for those who still didn't know Kirk is an ardent advocate of modularity :)

It's hard not to agree that more flexibility is a benefit. However, like any other technology, modularity shall be used wisely and appropriately.

Imagine your manager, who's not touched a line of code for 15 years if he ever did. Imagine him opening the local IT magazine and reading with a wet eye, that the new trend is no longer XML, nor Ajax, nor SOA, nor Agile, nor REST, nor Spring, BUT OSGI now!!! He doesn't understand what that means, what the technology does or implies, but anyway...imagine him relaying that crucial information in a corpo meeting, full of politicians that don't even remember what development consist in. Imagine that like a Dilbert cartoon, it'll be easier.

Ok now imagine them agreeing on the fact that the customer will necessarily want this technology (he's reading the same IT magazine), agreeing on the fact that everyone ought to sell it from the bottom of his heart, agreeing on the fact it will make projects more appealing, that it will enable the Company™ to sell more consultancy days, and finally agreing on an action plan in order to write a memo aiming at promoting OSGI throughout in the Company. I participate to those meetings, that's how it works. Difference is I still develop for my own company.

IMO there's no denying OSGI can bring an unvaluable benefit in some situations. Not all, far from all. As a developer or an architect it's your responsibility to explain these morons that OSGI is needed or not for a given project. When you're going to the doctor, you wait for the "expert" to tell you what treatment is appropriate, right? Antibiotics are not a rule, right? Same here.

Rogerio Liesenfeld replied on Wed, 2010/01/06 - 9:05am

What I don't understand is how can OSGi be equated to "modularity".

To me, proper use of the Java "package" keyword, together with an understanding of the principles of high cohesion and low coupling, is sufficient to have a modular system.
Modularity is about managing the dependencies inside and between packages, nothing more. There is no need to deliver each "module" in a separate jar file, and certainly no need to use a container which can deploy and re-deploy these jars separately for a running application. Of course, those things can be valuable in certain cases. But they go way beyond just "modularity".

Fab Mars replied on Wed, 2010/01/06 - 9:39am

I second that.

Well, that's true many people mixup OSGI and modularity. I'm one of them. That's because we're faced with a buzzword (describing something that's +/- a plug-in in most cases). Eclipse is THE good example.

Indeed, the benefits OSGI gives you in a modern Application Server goes way beyond just modularity. Thanks for pointing that out.

My initial comment stresed that OSGI should be used carefullly, sparsely, only when needed. Not blindly, nor for the sole pleasure of playing around with a new technology with your customer's money, forgetting the project and the busineess need at stake...

Cloves Almeida replied on Wed, 2010/01/06 - 7:19pm

I third that (does that exist?)


Modularization, like OOP ages ago, should come with large doses of concept. I want more articles answering:

Why modularize? What are the real benefits of it?

What real-world problem can be better/easier solved with this approach? Does the benefits cover the overhead?

In what kinds of applications should you do it? CRUD-like ERPs, integration projects, flashy webapps, packaged desktop apps, or maybe games?

Should you design it early in your project? Can/Should it be added latter?

How do I design it?

How should I feature- or unit-test it?

And finally, what are the technology enablers? Are they mature enough?

I'm going to standardize on this check-list for every new hyped (rightfully or not) technology.




Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.