What's the old saying? Everyone talks about modularity, but nobody does anything about it? Well, the OSGi community did something about it, and Peter Kriens has provided one of the best reads you're going to set your eyes on about the history, challenges, and attempted solutions at addressing the modularity problem. Most importantly, Peter shares his insights, and some community insights about what those in the OSGi community have learned over the past decade or so of development. One of those takaways? That a design guided by Unix packagers isn't the silver bullet you're looking for. Did you hear that, Jigsaw?

Anyways, being hard on Jigsaw is not what the article is about, although there are definitely some words of wisdom in there. The biggest words of wisdom? It's about the lessons leared over the years of doing modular develoment. There's some pretty solid insights in there. Give it a read.

From DLL Hell to an OSGi Haven: Because Sharing Shouldn't be Painful

Hmm.

Unix packages seem to work fine and scale to hundreds of thousands of packages. While OSGi seems to stutter with much smaller amount.

Oh, and OSGi also violates the KISS principle. If Jigsaw can be implemented with simple packages, then why complicate it?

I think this observation is spot-on. Instead of complaining about being misunderstood, the OSGi community should be working in the JCP alongsid the Jigsaw folks to figure out what really adds value for the larger Java community in terms of modularity. They must accept the fact that adopting OSGi as-is will simply not fly and they do need to make their case to achieve consensus with competing ideas.

Reza, where exactly does Peter complain about being misunderstood?

The OSGi community is ready to engage with Jigsaw within the JCP as soon as Jigsaw actually engages with the JCP. As I understand it, Jigsaw remains an internal Sun/Oracle project until such time as a JSR is created for Java SE 8 modularity. Of course, individuals from OSGi have already been collaborating with individuals working on Jigsaw for quite some time.

And we haven't even begun to discuss where JBoss modules fits into the mix...

My guess would be just another competing model to discuss in the JCP. We'll similarly present our pomegranate modularity ideas: http://blog.caucho.com/2009/06/10/pomegranate-modules/.

To be fair, he didn't; the title of the news post did: "failing to comprehend what OSGi..."

I think there is little question Jigsaw will probably be the canonical model of Java SE 8 modularity. It's good to know you guys are planning on collaborating there and most likely in Java EE 8 since that is where the most interesting modularity issues will likely be hashed out.

Last time we chatted about this you made a statement to the effect of "the modularity gold standard does not need a JCP rubber-stamp" that I have to say I thought was problematic.

I've been engaged in 277 (though was denied membership in the beginning), 294, 277 resurrection, and now active in Jigsaw. We proposed the Simple Module System as a bridge. All to no avail because there is basically a stone wall on the other side.

I am not sure anybody could've done more ...

When I look into problems with OSGi it is invariably because the code is not modular, it usually loads classes across module boundaries. This might be a common pattern in today's code but it is fact of life that this violates modularity. Jigsaw will therefore run in exactly the same problems as these are not OSGi problems but related to modularity. In this article I am trying to show what we've learned from living in a modular world for some time, lessons that seem to be ignored in Jigsaw (I am on the list, being fully ignored).

Unix packagers are great and I've learned a lot from them. However, they use tricks not available to us (recompiling, shell scripts at installation time, C macros) and require code to handle backward compatibility in their code. API based programming creates a triad in the dependency model which is as far as I know not handled in any packager. Java has some unique qualities that are in many aspects different than Unix packages, creating a module system without proper analysis does not sound like a good idea.

And though I am a great fan of KISS I think Einstein said it slightly more verbose but better: "Things should be as simple as possible, but not simpler."

I use OSGi in my product and it works well. I think its a good fit for software vendors who can invest in the time to understand it, but its too complex and arcane for end user developer. The error messages can get very obtuse (ClassNotFound vs NoClassDefError, packaging importing glitches and so on).

For most business development, WAR, EAR and JAR files are simpler to use and are "good enough". Few organisations invest in the short and long term commitment to create resuable "modules" (in the layman definition). If they do, dependency issues are usually resolved quickly and the app restarted.

OSGi needs to simplify, or hide the complexity behind excellent tools (and I mean good, allowing mortals to build and debug bundles), or risk becoming the 21st century CORBA.

The problem is backward compatibility with existing patterns. Most of these class loading patterns (ServiceLoader, factories, etc.) are not modular and will never be as they violate modular boundaries. JBOss modules is already running in the same problems and Jigsaw only does not have them yet because it has never been tested in the real world.

For modular code OSGi is very easy and due to its concerns for type safety you should not get class loading errors, I rarely, if ever get them. Unfortunately, there is a huge wad of code out there that is not modular, just like there was a huge wad of code in the 80s that was not object oriented. Until recently, much enterprise code did not use Spring. In the next 7 years we will double the amount of code in the world. What OSGi tries to do is provide a solid no-shortcut platform that allows us to write that next huge wad of code in a modular way and thereby reducing the development cost.

Anyway, application developers should never see OSGi APIs and tools should take care of the packaging. I use Declarative Services with annotations and for app code rarely have to use OSGi API or write XML. OSGi APIs are reserved for middleware developers, and for them I think it is a wet dream API as it allows them to discover componenents, provide system extensions, and in general make the life of application developers easier without breaking modularity.

Anyway, application developers should never see OSGi APIs and tools should take care of the packaging. I use Declarative Services with annotations and for app code rarely have to use OSGi API or write XML. 

Maybe i am missing/misundertanding something, but I am an "application developer" and see the the use for OSGi within the app.  I have UIs based on Eclipse RCP and RAP and thus need to have all my code be plugins. Currently, our server code is just jar/war based but at some point I plan on using OSGi. Of course, not every app needs to do this, but I see it needed quite a bit. They need their code to be modular but all they can do is copy-paste or do a lot of configuration to hide things. I think you talked about needing to be modular up front. The issue is that most people don't start that way. 

Maybe this is not really using the OSGi APIs :).

Peter, it seems you do a lot of OSGi (duh) so do you use Eclipse? If so, do you have lots of plugins that you develop at the same time? And if so, I am curious as to how you manage it. FYI, this goes for anyone. What I mean is.. you should work with the binary artifacts during development unless there is a coding change needed. Then the code version of the "plugin" that needs to be changed should be checked out of the code repository and used instead of the binary until development is complete.

In my experience, OSGi is a trainwreck. It's meta-data is complex and there's little that fail-fasts when you configure it wrong. The fact that OSGi resolution is NP-complete is a show stopper for me. JBoss modules looks far simpler to configure and faster.

But my largest gripe stems from the paradigm mismatch with maven/gradle/ivy dependencies (GAV's, scopes, ...) and versions (1.2.3-SNAPSHOT and 1.2.3.beta1.SNAPSHOT is not an accepted OSGi versions). I am not saying this is an OSGi core defect, nor saying there aren't attempts to fix that (tycho, felix-plugin): I am just saying it causes a lot of headaches and the bottem line is OSGi's benefit is not worth the hassle it creates to keep stuff in sync. I wonder want JBoss modules's plan is on the maven/gradle/ivy integration front. I heard that Jigsaw is going to import/reuse the maven repository metadata, so they're definitly looking at it.

I am not sure this post was related to the article I wrote? However, I am interested in what mandatory metadata you consider unnecessarily complex?

For each one of them there are use cases that several companies deemed very important and we've spent a great deal of effort to keep the metadata as simple as possible. It would be interesting to discuss what use cases you consider unnecessary or have a much easier solution than OSGi's metadata.

The idea behind OSGi is good: a list based classpath is broken and only a graph based classpath can truly fix it. What makes it confusing is that it mixes 3 concepts in a single manifest.mf text file: package visibility, module dependencies and services lifecycle.

Excluding the bells&whiles metadata (url, license, ...), so including only the dependency metadata, here's a list of the variaty of tags: Export-Package, Private-Package, Require-Bundle, DynamicImport-Package, Bundle-Activator, Import-Package, Bundle-Localization, Bundle-ClassPath

Another thing that bothers me is, almost every eclipse plugin uses "Bundle-ClassPath" (as a workaround for all kinds of problems), which basically means "ignore OSGi and just put this jar on the classpath".

But again, these are small papercuts, the biggest problem - by far - is that we've already specified our dependencies in maven/gradle/ivy/buildr (Don't Repeat Yourself).

How do you repeat yourself with the maven bundle plugin? The only additional information is what packages are shared with others, which is not in the scope of maven. And you can even specify this in the POM?

Kind regards,

   Peter Kriens

The real question is how we can make sure that Jigsaw does not break OSGi, and that perhaps OSGi can leverage Jigsaw's intrinsic capabilities to simplify the implementation -- if not the surface area -- of OSGi.

We shouldn't look at these as competing technologies; Jigsaw is not actually trying to do all of the things that OSGi already delivers. Furthermore, OSGi members and developers are already involved in shaping Java 8, including Jigsaw. We need to think of these efforts as complementary and cooperative, instead of pretending it's a wrestling match ;-)

Peace,

Cameron Purdy | Oracle

The OSGi specifications have moved beyond the original focus of service gateways, and are now used in applications ranging from mobile phones to the open source Eclipse IDE. Other application areas include automobiles, industrial automation, building automation, PDAs, grid computing, entertainment, fleet management and application servers.- Madison Pharmacy Associates

This really sounds interesting regarding the modular development where we can even learned words odf wisdom. 

Incredible Discoveries

Yes I agree with sound shift. "At most" wouldn't work here as the expression "at most" is usually used to express quantity.-CWD Construction