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

OSGi: Complexity is NOT The Problem

04.16.2010
| 7616 views |
  • submit to reddit

The editors at SD Times have proclaimed that OSGi is too complex. Unfortunately, they miss the mark, and the following statement taken from the article is misleading.

We believe that OSGi, rather than simplifying server application development, has actually made it more complex, and there aren’t sufficient benefits to justify the added complexity.

This statement should have been tempered with context. It is not universally applicable, though is made to sound as if it were. OSGi may face challenges, but complexity of the OSGi framework is not one of the long-term inhibitors to adoption.

Technology Adoption Lifecycle

All technology goes through various phases of adoption. A lack of platform support and tooling may be inhibiting adoption today, but that is today’s problem, and one that is being dealt with. And there is a stark difference between complexity brought on by lack of tooling and platform support versus complexity associated with an ill-conceived idea. OSGi suffers today from lack of enterprise-class tooling and platform support. OSGi is not an ill-conceived idea.

Whenever an organization adopts a new technology, they’ll undoubtedly face some degree of initial complexity. New technology takes time to learn. As the innovators and early adopters continue to use OSGi, tooling is going to get better and developing modular applications using OSGi is going to get easier.

The question you must answer is whether the pain of adoption today is worth the gain of a modular architecture. There are many factors to consider when answering this question, but as the technology matures, the question will be easier to answer. As I’ve alluded to, other factors that have little to do with OSGi’s technical benefits will likely determine if it’s is able to cross the chasm.

Long Term Value

But the article’s biggest flaw is in stating:

And what’s the benefit again? Enterprise developers have written many, many server-side Java applications without using OSGi.

It’s important to understand its value over time. Let me pose some simple questions.

  • Is Spring too complex? It is far easier to create an application with concrete class references than it is to use dependency injection and abstractions.
  • Is Hibernate too complex? It is far easier to use JDBC than it is an ORM framework.
  • Is unit testing too costly? It is far easier to forego unit testing than it is to create a robust suite of tests.

Yet each contribute to more flexible software systems, and in that, there is significant benefit. So it is with OSGi and modularity, as well.

Leveraging OSGi to design modular applications will require us to learn new concepts, tools, and design paradigms, but there is no doubt that modularity has a tremendous upside. This makes the SD Times article paradoxical. OSGi does not increase complexity; the very benefit of modularity is that it helps us manage complexity.

More on Benefits

If you’re interested in exploring some of the benefits of modularity, you can start with the following:

From http://techdistrict.kirkk.com/2010/04/15/osgi-complexity-is-not-the-problem/

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

Comments

Geertjan Wielenga replied on Fri, 2010/04/16 - 2:43am

There's really no need to defend modularity at all. If someone has investigated it and rejects it, just leave them alone to drown in their JAR hell. :-) Probably they're not programmers though, or haven't created large-ish applications, so their opinions don't really matter.

Fabrizio Giudici replied on Fri, 2010/04/16 - 5:34am in response to: Geertjan Wielenga

I can't but agree, of course.

Ronald Miura replied on Fri, 2010/04/16 - 7:01am

If you consider only the DI aspect of Spring, using it IS more complex than not using it. As many say, you don't need a framework to do DI. It is so widely used not because DI (there were other DI containers before), but because it solves a whole lot of problems developers would have to tackle themselves otherwise, including some incompatibilities between Java EE implementations.

Hibernate IS too complex, most (average) developers never get it completely. They will, eventually, become productive with it (which is why it is used anyway), but most of them won't be able to make it performant, for example.

Unit Testing IS too costly, and the whole "if you don't TDD you are not a professional" thing is bullshit. Ask Jeff Atwood about the test coverage of StackOverflow. Which doesn't eliminate the necessity of testing, and the advantages of using unit testing to test many kinds of software (libraries, low-level APIs, etc.).

OSGi does give us means to manage complexity, but OSGi itself also adds compexity (as does every technology you add to a project). If you don't need a mechanism for manage your current (without OSGi) complexity, and is happy with a monolithic application, you'd definitely only add complexity by using it. It is a lifesaver when you do need its level of isolation, though.

Jar hell is not caused by the lack of isolation between jars or modules, but by the lack of care when designing (or not designing at all) their interdependencies. For the average Java EE web application, using Maven to resolve jars and their versions, or even just thinking a little about what you add to WEB-INF/lib, would be more than enough.

OSGi is a really nice piece of technology but, just like everything else, it is not a silver bullet.

That said, no, the problem of OSGi is not complexity itself, but trying to sell it as an everybody's need, instead of as a solution to a particular problem, which you may have, or not.

Rob Abbe replied on Fri, 2010/04/16 - 8:00am

There are certainly complexities and due to the fact that Java was not designed with an OSGI style of modularity in mind, implementing OSGI in a project can feel very hackish.

As an example, some Java APIs such as ImageIO make use of the service provider interface (SPI) to allow plugins to be added at a later time.  ImageIO was designed with the assumption that plugins would be accessible from the root class loader.  This makes it difficult if not impossible to use ImageIO from a bundle that requires a plugin that is contained in a bundle because the code that searches for plugins in ImageIO will not be able to see plugin classes or the metadata that describes them.  If the ImageIO api were in it's own bundle, things would be better.

The benefits of modularity cannot be denied, but it does seem like a lot of time can be exhausted searching for solutions to issues that would not be an issue if modularity had not been an afterthought.

 

Scott Ferguson replied on Fri, 2010/04/16 - 10:33am

Modularity itself is good, but OSGi's implementation is not. People who think OSGi is over-complex for its benefits are not opposed to modularity; they're opposed to OSGi. For example, the upcoming Java language support for modularity in JDK 7 is a very good thing, and really it should be discussed more instead.

This article itself doesn't argue that OSGi modularity is a good one, it simply argues that modularity itself is good, which doesn't address the value of OSGi itself at all. For example: "OSGi does not increase complexity; the very benefit of modularity is that it helps us manage complexity."

James Imber replied on Fri, 2010/04/16 - 10:46am

Just a question:  Is Spring == DI in your mind?

If not, what do you include behing this umbrella brand?

* AOP functionality
* Integration with Toplink, Hibernate, JDO, and iBATIS SQL Maps
* abstraction layer for transaction management
* MVC web application framework

anything else?

Jacek Furmankiewicz replied on Fri, 2010/04/16 - 12:21pm

OK, so here is a simple example of OSGi complexity from a real-life case

public void doSomething(String value) {

     String newValue = value;

     ...some other processing...

}

 First line in this method suddenly craps out with a ClassCastException and the wonderful message of "cannot assign java.lang.String to java.lang.String"...a telltale sign of OSGi classloader issues.

We have a huge app with hundreds of bundles, some our own, some from external repos.

Managers are breathing down our necks, support is escalating, etc, etc. And we're up a creek without a paddle 'cause tracking this type of issue in OSGi is like looking for a needle in a haystack.

Things like these used to happen to us every time any major part of the underlying platform was changed...in totally different, random parts of the app. It was a nightmare.

If I have a Spring DI problem I know exactly where it is. With an OSGi problem like the one listed above...good luck.

Stuart Mcculloch replied on Mon, 2010/04/19 - 9:58am in response to: Jacek Furmankiewicz

That's a telltale sign of any custom-classloader approach, not just OSGi. In fact something else must be going on in your application because the OSGi standard states that all "java.*" packages must be loaded from the parent classloader, just like in the classic Java delegation model. This means that any class cast exception involving a "java.*" package is either a bug in the particular OSGi framework you're using or there's another (non-OSGi) custom-classloader in the stack that's not delegating properly.

A suggested first step would be to print out the class loader for the value object as well as the String.class class loader. You should see that they are different (hence the exception) - the class loader types should also suggest which particular class loading code is involved (OSGi or otherwise) and point you towards the cause/solution.

BTW, what framework are you using and have you reported this to the appropriate mailing list? (I haven't seen anything like this reported on either the Felix, Equinox, or general OSGi mailing lists)

Jacek Furmankiewicz replied on Tue, 2010/04/20 - 10:14am

Well, originally in my previos company we were using Equinox.

 In my new company,we acquired a product that was written on top of OSGi (in Glassfish, using some custom form of Felix if I recall).

These errors occurred on BOTH of them. It was funny to see the same darn ClassCastException errors on OSGi apps in two separate companies I've worked for.

Never seen anything like in my regular, good, "working as designed" Maven/Spring/Hibernate/Jetty apps.

Stuart Mcculloch replied on Wed, 2010/04/21 - 1:48am in response to: Jacek Furmankiewicz

  "Never seen anything like in my regular, good, "working as designed" Maven/Spring/Hibernate/Jetty apps."

Same here for OSGi applications... sure I've seen class cast issues for domain (non-java.*) classes while helping out on the forums, but that's usually either caused by incorrect imports, embedding extra classes by mistake, or misbehaving proxy code. So far I've never seen a class cast exception involving java.* classes and I can't remember anyone mentioning such a problem on the forums either, which is why I wondered if you'd reported it - the Apache Felix list is usually quick to respond if you ever run into this in the future...

Jacek Furmankiewicz replied on Wed, 2010/04/21 - 9:02am in response to: Stuart Mcculloch

I am pretty sure in both cases it was lack of OSGi experience, not anything to do with the containers.

Either way, my point is that for the benefits that OSGi brings, it does come with a lot of potential baggage and when it blows up...it blows up REALLY hard. Seeing a ClassCastException would clear out a room of developers in no time...no one wanted to be assigned to the task fo trying to track it down.

From what I recall, building the app and fiddling with all the targets in Eclipse (different one for the client-side and server-side) was a pain as well. I also recall that the automatic Eclipse tooling would put all the dependencies on one super long line of text in Manifest.mf which made it virtually impossible to compare it against CVS and see what has changed.

Little things adding up to a lot of frustration. Outside of the chief architect (who mitigated the OSGi move and whose job was on the line), no one on the dev team liked OSGi at all. It was a pleasure to do maintenance on our old version of the app (prior to it being migrated to OSGi) where everything was just simple, straightforward and easy to debug.

The reason why we adopted OSGi back then 'cause the company wanted to have one common platform for all their disparate application development.

We managed to deliver the same thing at my new employer with a single, well integrated Maven pom.xml file. Sure, it took me two days to figure out all the dependencies (Spring, Hibernate, Apache CXF, etc.) but after it was done, it's been smooth as butter ever since.

 

 

 

 

Comment viewing options

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