File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes OO, Patterns, UML and Refactoring and the fly likes is OSGi mature enough yet? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "is OSGi mature enough yet?" Watch "is OSGi mature enough yet?" New topic

is OSGi mature enough yet?

kato Kwong

Joined: Sep 23, 2011
Posts: 27
Hi Kirk,

Your book sounds interesting.

I just happen to have started using OSGi by trying to deploy an existing application that is designed for web application servers and am having a lot of trouble with dependencies and class loaders.

Reading some of your introduction, it seems as though some of my problems are because my application is not designed in a modular fashion: I guess I need to pay more attention to the physical design.

But if the theory is valid and useful right now, it seems to me as though the tools and containers I am using are not very robust, some may say flaky (I am using Karaf/ServiceMix 4.4).

What are your thoughts on this, are the tools mature enough for modular JAVA? Or should we wait for java 8 or maybe 9 to avoid the early adopter struggle?

Kirk Knoernschild
Ranch Hand

Joined: Apr 16, 2012
Posts: 41
I believe you should be designing modular software right now. Whether you decide to use a modularity framework like OSGi is a separate decision and is driven by your willingness to deal with some of the challenges. By designing modular software now, you're positioned to take advantage of runtime support for modularity when you're ready.

OSGi is a very mature technology. What's still relatively immature is that the app server vendors have only been working to incorporate OSGi into the app platforms for the past couple of years. Depending on which app server you're using, you may find it's more or less mature. Tooling for the enterprise developer is also maturing.

Dependencies and classloader errors are common for folks new to OSGi because the way OSGi handles these things is a bit different than what we're accustomed to. For instance, if your code uses Class.forName in an OSGi environment, you're likely to have problems. Read this post by Neil Bartlett as an example. OSGi itself is mature enough, but there are some anti-patterns we have to avoid.

Visit the book's website at where you can review all 18 patterns and download an excerpt of the book. There is also a mobile web application available that you can take with you wherever you go.

Twitter: @pragkirk
kato Kwong

Joined: Sep 23, 2011
Posts: 27
Thanks for the links Kirk.

Talking about the relative maturity of OSGi and application server vendor OSGi support, there is also the OSGi readiness of 3rd party frameworks to consider.

Being aware of the different class loading paradigm so as to avoid coding pitfalls in my own code is one thing. Another is using 3rd party frameworks such as Hibernate.

Is there any virtue in the OSGi specification being mature if container and framework support is not? I guess this is an evolution...

As you say, by making my code more modular I may resolve some of my issues, but at least I can be satisfied that I will have written a better application
I agree. Here's the link:
subject: is OSGi mature enough yet?
It's not a secret anymore!