I was happy to see that InfoQ took up the JSR 277 / JSR 291 stuff again and did a pretty good job weaving together the recent activity (including my own call to interest on the subject).

I did want to mention one thing that I don’t think I’ve mentioned before about OSGi and JSR 277. Some people have the impression that OSGi is complex and powerful and that JSR 277 is simpler in some way. I think if you actually read the JSR 277 spec and the OSGi 4.1 spec you’ll find that neither is simple. Both clock in at hundreds of pages. The problem of managing component based systems is filled with inherent complexity, especially when you take on stuff like dependency management based on versioning schemes, module lifecycle, security, classloading, etc. JSR 277 takes on an additional kind of complexity with the repository aspect, which is in some ways the most divergent and interesting part of the spec. Read some of the JSR 277 mailing list archives and I think you’ll see some intense discussion of the thorny issues that need to be sorted out.

What I see in these specs is not complexity due to bad design but complexity due to trying to deal with a complex problem. Sometimes the simplest possible thing you can do is still pretty nasty. Sucks to be us, right?

I think both of these specs are actually pretty good. They’re both well written, relatively clear, etc. I suspect the OSGi spec might be a little more complicated, but that’s because it is version 4.1 and takes into account the years of experience from heavy real-world usage.

So, in the end my question is whether we will end up with a JSR 277 that is actively or even mildly incompatible with OSGi. I certainly don’t see OSGi going away. It’s way too heavily used already and will have another 2 years of adoption before 277 is even minimally available, probably 3-5 years before people are really making a choice.

On the flip side, JSR 277 will be baked into the JDK. It will undoubtedly become at least the Sun-recommended choice for module format and deployment. It has already been stated as the preferred archive format for the next Java EE spec. To me, this sounds like something that will split the market in ways that will hurt both developers (who will have to do extra work to ensure deployments work well in both environments) and to users (who will have to care about whether a module is compatible with OSGi or the Java Module System).

Ideally bundles and modules would be interchangeable and usable in both forms. That sounds easy (like just packing extra metadata into the archive) but there are a number of very subtle differences in the ways that OSGi and JSR 277 define dependencies, manage resources, etc. I haven’t seen much in the way of resolution of those issues, despite a lot of discussion.

So I then have to ask whether JSR 277 is re-inventing the wheel (to some degree) only to split the market and hurt the overall community. This is a somewhat rhetorical question of course. I believe that everyone involved here is truly trying to build something great. But sometimes I think we need to step back and see the bigger long-term picture and ask some questions about our goals.