http://www.coconut-palm-software.com/the_new_visual_editor/doku.php

In the end, I guess where we part ways is that I think OSGi can be made to work in the long run.

For instance I think that the tooling can and is being improved. Compilers can be improved, and actually the Eclipse compiler is very OSGi-aware and provides great feedback.

You argue that modularity is something that can be achieved using common sense and without a framework. This is undoubtedly true, but only by a very small set of developers. It’s also true that OSGi can be abused to create really ugly code, but you could make this argument about a lot of technologies.

I keep coming back to the parallel transition from procedural to object-oriented technologies. Many of these same arguments took place then. We don’t need OO. OO can be abused and made to look procedural. OO puts too much of a burden on developers and limits their freedom.

Eventually OO became mainstream, and I think that modularity will as well. These shifts are incremental changes that increase “the granularity of our aggreations”, as Steve McConnell puts it. Whether this modularity will be in the form of OSGi or some other technology (or built into the JVM itself) remains to be seen. But in the end, modularity is too useful to be ignored.

Both of them cause runtime issues. Personally, if I had a higher interest in runtime issues, I would have switched to groovy/grails long time ago. They, btw. also solve this “private package” model.

Another open point imho is deployment. OSGI is lacking some sort of container format (something similiar to a war): a single file containing the entire application, that gets deployed onto the server. Using OSGI in production for a large scale, I can tell you, that anything else is very painful and error prone. Updating several servers at the same time, it’s more handy when there is only one file in a concrete version that must be deployed.

Having modularization on the one hand is nice, but on the other hand, it’s trying to enforce something via a platform that should actually be part of a developer’s common sense. Anyone too lazy for modularization could still (with OSGI) declare all modules public and use dynamic imports. What this convention actually does is, making it harder to be “a nice developer” because the good developer needs to go with all the extra effort to declare his public/private packages with their version and so on. While the “mean developer” will just export all packages with version 0 and use dynamic import everywhere.

For downloading bundles from the internet: You could just download and use them, if they had no dependencies to other bundles. Most of the time, I found myself, patching manifest files of very common libraries (not all of the apache-common libs have an OSGI manifest) so that I could just use them. If these libs do classloading magic themselves (and a lot of them do), poor you.

I think, OSGI is not ready for three reasons:
It’s lacking tool support (and a compiler that understands the manifests)
Many 3rd party libs don’t come OSGI friendly
OSGI is a very restrictive spec, where you need to declare a lot of stuff. This causes way to much overhead. In many ways, it complicates too much.

Surely, no more overhead than if you were to implement the service infrastructure yourself?

>Next trouble comes with building OSGI modules. OSGI has some
>assumptions on java, the compiler does not know: Imagine, you have bundle X,
>containing com.x.foo.FooBarClass. Then you’d define com.x.foo being a
>private package. So during runtime, FooBarClass will not be available to other
>bundles. Now you’re working on Bundle Y, having a dependency to Bundle X.
>Somewhere internally, you end up, referencing FooBarClass. From any java
>compiler’s perspective this is fine – as long as X.jar is in the classpath. During
>runtime, however, you’ll either get a CassNotFoundException or (worse) a
>NoClassDefFoundError. Using OSGI reintroduces a lot of errors that one would
>normally know from dynamic programming languages.

I think this is the fault of the tooling – not OSGi. If you tool is dumb enough to polute the build-namespaces with the non-exported packages, this will happen. Unfortunately, most of the tools I use – have this problem (e.g. maven + eclipse duo). I am also looking for a solution to this right now.

>Then there’s maven (and all other build tools doing dependency management):
very fine, to use Bundle X in both Version 1 and 2. All these tools however will
>detect a version conflict and try to fix it, by only using version 2.

Again, I think this is the fault of the tooling. Maven is not smart enough to understand OSGi dependencies. In fact maven is very stupid about version in general – and to this day I can’t figure out how the hell it works.

>Another problematic area is the OSGI spec: It really IS a big bunch of paper.

Surely, R1 is not so big? And that should be sufficient to get you acquainted with the overall architecture of OSGi.
Also you don’t really need to know all the details unless you are actually writing an “implementation” of OSGi.

>The concrete OSGI implementations of the other hand will only support a
>subpart of that spec. Lacking in documentation what features are there and
>what are missing.

I think implementations are pretty clear as to WHAT they implement:
http://felix.apache.org/site/osgi-specification-implementations.html
http://www.eclipse.org/equinox/

>In my opinion, the advantages of using OSGI come with a very high price. A
>price, that you’re probably not wanting to pay. Leveraging a DI framework (like
>spring), that allows multiple contexts and doing some service import/export
>managment might be a very good alternative choice. Using OSGI, you should
>really ask the question: “Why” first. and only if there are no alternatives to
>OSGI (and there are), use that technology.

There are no alternatives to OSGi – maybe jboss (which is using osgi itself). Also DI – is just a small part of what osgi can do. In my opinion the most important aspect is the “modularization” and dependency enforcement.
The notion that my application will not run – unless all the pieces are there – makes me sleep much better, knowing that I never have to debug things like missing or incompatible bytecode.

Only in osgi can I go and download a “bundle” from the internet, and drop it in my container – and not have to do any kind of “install” or “compile” steps. It is truly a “framework platform” of the future! WOHOOO!

Now if only we could have Scala as first rate language for OSGi – it would be much more popular.

Surely, Encapsulation and Service Exports is a good thing – this is what OSGI is about and this is, what’s working fine.

How to set this one up, is the problem. If you’re really doing OSGI, you’ll need to create dozends of modules. Each one would (normally) come as a maven module, bringing it’s own overhead. Working on such a project effectively means making large jumps around various parts in your codebase. This leads to a lot of overhead when doing maintenance and/or debugging.

Next trouble comes with building OSGI modules. OSGI has some assumptions on java, the compiler does not know: Imagine, you have bundle X, containing com.x.foo.FooBarClass. Then you’d define com.x.foo being a private package. So during runtime, FooBarClass will not be available to other bundles. Now you’re working on Bundle Y, having a dependency to Bundle X. Somewhere internally, you end up, referencing FooBarClass. From any java compiler’s perspective this is fine – as long as X.jar is in the classpath. During runtime, however, you’ll either get a CassNotFoundException or (worse) a NoClassDefFoundError. Using OSGI reintroduces a lot of errors that one would normally know from dynamic programming languages.

Then there’s maven (and all other build tools doing dependency management): they are taking wrong assumptions over versionings. Having OSGI, it may be very fine, to use Bundle X in both Version 1 and 2. All these tools however will detect a version conflict and try to fix it, by only using version 2.

Another problematic area is the OSGI spec: It really IS a big bunch of paper. The concrete OSGI implementations of the other hand will only support a subpart of that spec. Lacking in documentation what features are there and what are missing.

In my opinion, the advantages of using OSGI come with a very high price. A price, that you’re probably not wanting to pay. Leveraging a DI framework (like spring), that allows multiple contexts and doing some service import/export managment might be a very good alternative choice. Using OSGI, you should really ask the question: “Why” first. and only if there are no alternatives to OSGI (and there are), use that technology.

Actually I disagree :-)

I think the first thing developers should learn about OSGi is Services. Of course, using DS to simplify the development of service components, rather than messing about with activators and stuff (so, I agree with you about Lifecycle).

Once they get Services, they can then move on to how to use the module layer to enhance the development cycle, hide implementation classes, evolve APIs etc.

Anyway thanks for the namecheck on bndtools!

“DI needs to break encapsulation in order to work.”

Exactly! But this is not a problem with encapsulation, it is a problem with DI.

The DI framework sits at the centre of the system, grabs an object from here and an object from there and rams them together. To do this it reaches into the innards of each module, tearing out objects at the time it chooses, whether the modules are ready to provide an object of that type — and at that time — or not. The result is horribly fragile because if any individual module fails, then the whole DI framework fails.

OSGi’s solution is wonderfully elegant: just reverse the arrows. Instead of a central component that pulls from every module, have the modules push into a central registry. This allows the modules to remain completely encapsulated with NO externally visible packages. It also solves timing issues: the modules provide objects only when they are ready to do so. And it is robust: the failure of one module does not take down the whole system.

It’s really quite beautiful. And you don’t need to dispense with DI as a programming technique, in fact in OSGi we still usually employ DI framework inside our bundles. The key is not to allow the DI to reach across modules.

Thanks again for the article Patrick!

I do sympathize with the idea that OSGi is over-engineered, and as a trainer I’ve encountered many developers who feel overwhelmed by the technology. I also believe that it would be much better to have modularity enforced in the language, though I don’t think the current approach for Java 8 is the way to go.

It’s my opinion that most developers would get a lot out of OSGi if they focused on the Module layer and ignored the Lifecycle and Service layers, at least initially. It would also be great if there was extremely simply tooling that made it easy to work with the Module layer. Neil Bartlett’s BndTools is a good start, but it’s still way too complex.

Having said that, my experience with OSGi has been great. I work with it in the context of Eclipse RCP, and it’s completely changed the way I write code. OSGi also allows us to package and deploy code in ways we never could before. I can’t imagine going back.

Thanks for the thoughtful comment.

— Patrick

My experience with OSGi however has not been particularly pleasant. My intuition is that it is excessively over-engineered and trying to solve too many problems all at the same time. While some of the goals may be great ideas, the actual implementation is far more important. If the problems outnumber the benefits, then it is time to reconsider the approach. Also, this type of paradigm should probably be based in the language were it can be handled properly, not some external add-on which can only be partially integrated.

Paul.