Who Needs This Book?

Not every Java programmer is excited about OSGI. If you work in a slow moving, buttoned down environment, you may have no incentive to decouple your projects and their many, possibly competing, dependencies. Everyone on your team agrees that productivity is not an issue. Your world is good, without OSGI. 

 

Those of us who live in a world of bi-weekly milestones and lots of high risk experiments with new technologies - we are not so lucky to just be able to ignore the slowdowns that come with jar hell, and tightly coupled projects. That's when we need OSGI, which means that's when you need a book like Modular Java: Creating Flexible Applications with Osgi and Spring (Pragmatic Programmers), which is Craig Wall's latest book.

 

Just for the record, even after studying this book carefully for a few weeks, OSGI is still not for the faint of heart. Craig is quick to point out in his book that it is not as complex as it is reputed to be - but that's his job - to make it seem simple.

On the face of it, OSGI solves jar hell problems by

  1. limiting your jars to versioned jars
  2. loading your versioned jars into separate classloaders
  3. restricting entry points to specific packages

That's not so complex, is it? Not until you write a manifest file by hand, anyway. Don't even think about it.

 

10 Years Later, OSGI Gets Simpler

In this book you will learn how to do OSGI an easy way.

 

OSGI accomplishes it's magic via jar manifest files. These can be tricky little devils, which is where it helps to follow in the path of Craig Walls rather than learning it the hard way.  There are many different tools and projects which can help you automate this process, and Craig has spent years experimenting with each and coming up with an approach for getting this done with the least amount of pain and discomfort.

 

After finishing this book, you'll be able to blast through the process in minutes, and get your projects OSGI enabled.

 

The Difference An Experienced Author And Lecturer Can Make

The best part about Craig Walls as a writer and a lecturer is his passion and experience combined. This is at least his third book, and he stays on the lecture circuit permanently, so by the time you read one of his books or hear one of his lectures, you're reading or listening to the nth time he's done it, and it gets better each time.

 

What results is great books like this one, which is super-easy to follow. You can blast through it in a weekend and get right to the heart of the matter. Really great stuff. Especially helpful in an area such as OSGI which can be painfully obscure at times.

 

Should You Read This Book?

If you're going to do OSGI or if you are sitting on the fence, this book is a quick read and perhaps indispensable. OSGI is too easy to not understand it, and it takes someone like Craig to make it easy and breezy enough for you to get through quickly.

 

You may discover, however, that this book is necessary but not sufficient. The problem is not with the book, but with OSGI itself. The design of OSGI is to fail - in order to prevent jar hell it is designed to fail, or not deliver results - unless you get it right, and "right" can be a narrow window.

 

In other words, the book works exactly as I describe: It will get you through in a quick weekend and you will both understand and be able to execute the modularization of your code as it is outlined. But when you bolt up your own code, it might not work, and that weekend won't be enough to get past the rather arcane and hard to imagine reasons why your freshly decoupled code modules now won't quite talk to each other.

 

The pattern which OSGI helps to solve is the Big Ball of Mud Pattern - where all the code goes into a single classloader as a big ball of mud.  But if you spend a weekend trying to fix that problem, and now you can't get all of your projects to talk to each other and you have no more weekend left, you may end up longing for that big ball of mud, or a little more weekend to experiment with the resulting code.

 

I was also a little bit curious as to why he gives such short shrift to Eclipse as an OSGI tool, being the Eclipse enthusiast that he is. Perhaps it's because Eclipse disguises OSGI as an Eclipse plugin. Either way, I've been pretty successful with this approach without even trying. Now that Craig's book has shown me how OSGI works, I can use the Eclipse Plugin style of OSGI with full understanding.

 

  

My last problem with this book is that it may have been written a year or two too early. Maven seems like it may be making some serious breakthroughs with OSGI in coming months and years, and we might wish for Craig's wisdom when that happens. I know that I'll be monitoring his tweets for just such a publication.

 

 

This book is superbly helpful. Recommended. 

 

  1. Pete Carapetyan on Tue, 11/24/2009 - 10:42

     These comments were were sent to me by private email, posted here with his permission:

     

      * True statement that the book outlines a path of starting a

        greenfield project in OSGi. I don't really show how to migrate an

        existing project to OSGi. I leave that out purposefully because

        there's no one magic prescription for that ailment. Everybody's

        project is a little different and migrating from the big ball of

        mud to nice clean OSGi modularity will be different for everybody.

        When I speak about OSGi, I am now including a few slides that

        describes a general approach, but even that may fall apart on some

        really ugly code.

     

      * Why did I not discuss Eclipse much? Primarily because *EVERYBODY*

        talks about Eclipse when doing OSGi. My initial foray into OSGi

        left me thinking that I *must* use Eclipse because so many

        articles are written with an Eclipse slant. I didn't want to write

        a book that gave that impression. Maybe I swung too far to the

        other side, but I hope my readers know that Eclipse is not a

        prerequisite to OSGi. Also, I don't care so much for how the PDE

        has a plugin-centric feel to it...even for someone like me that

        can make the mental mapping of plugin concepts to OSGi concepts,

        it can be confusing at times. I really didn't want to keep

        explaining the PDE throughout the book...I thought it would

        distract from the central message.

     

      * Written a year or two too early? Of course it was. Everything I

        write is ahead of its time. :-) The problem with the topic of OSGi

        is that it's shifting constantly and I already wish that I had

        waited a bit. The OSGi Blueprint service, for example, is

        something that I wish was complete when I wrote the book. Apache

        Felix 2.0.0 is now more capable than before. And Karaf makes it

        even better. And the tooling with Maven continues to improve. So

        yes...a bit early. But even if I wrote it a year from now, it'd be

        ahead of its time again because even more cool stuff would appear

     

  2. Post new comment

    The content of this field is kept private and will not be shown publicly.
    • Web page addresses and e-mail addresses turn into links automatically.
    • Allowed HTML tags: <a> <p> <span> <div> <h1> <h2> <h3> <h4> <h5> <h6> <img> <map> <area> <hr> <br> <br /> <ul> <ol> <li> <dl> <dt> <dd> <table> <caption> <tbody> <tr> <td> <em> <b> <u> <i> <strong> <del> <ins> <sub> <sup> <quote> <blockquote> <pre> <address> <code> <cite> <embed> <object> <param> <strike>
    • Lines and paragraphs break automatically.

    More information about formatting options