OSGi vs. Sun

Peter Kriens has posted an interesting blog entry that pretty much summarizes the current situation between the OSGI camp (aka JSR-291) and the Sun JSR-277 and JSR-316 camp. I have to say that I pretty much agree that as far as technology goes, I would much prefer that Sun be more open to adopting OSGi as a standard technology for all of the Java runtimes (Java ME, Java SE, and JavaEE). OSGi has proven itself already and has had years to evolve and become what it is while being driven by real world requirements and usage.

I think the big conflict between Sun and OSGi is a very simple political battle over control and licensing. Technology be damned! Once again the politics of Java are eschewing the common sense and logic that would normally prevail among intelligent individuals. I have been very hopeful that Java was making a resurgence in its ability to innovate and evolve, but this is the kind of thing that makes me worry…

To be perfectly fair, I think the resolution to this lies just as much with the OSGi Alliance as it does with Sun. I am not privy to the details of such conflicts, but I am confident that there is a fair amount of ego involved in this issue on both sides and having an external company structured around a “specification” such as OSGi does not lend itself well to being community driven. However, I will continue to use OSGi and recommend it because I feel that it is far superior to any of the “from scratch” specifications being authored in the JCP, and I can only hope that in the long run common sense will prevail in some fashion with both parties involved.



9 Responses to “OSGi vs. Sun”

  1. Hani Suleiman Says:

    This is the problem with OSGi people, they rant and rave in public, whereas Sun employees exercise more restraint and so end up looking like the bad guys.

    JSR-277 is bending over backwards to ensure it is compatible with OSGi, but you don hear that because those bigots are upset that they’re becoming just an implementation instead of *the* implementation. OSGi will support 277 (after all, 277 has 2 OSGi people on the EG). OSGi will offer features above and beyond what 277 requires (commonly know as proprietary extensions/vendor value add on top of a base spec).

    The IBM people are just upset that they have to compete with other implementations, and that the resultant spec allows other implementations since its designed for that, rather than being designed as just a foundation for OSGi by only taking its needs in mind.

  2. Karsten Voges Says:

    It probably is the fault of both sides that their seems to be no common base (or JSR) for the single problem.
    Still I would vote for OSGi since it is well designed, thought off and widely used. Besides it should be possible to address a more general problem and specify a ground where OSGi is rather building on top. Just like we have with Hibernate or Toplink and JPA, where JPA is the common ground, but there are Tools with further features.

  3. Chris Custine Says:

    Hani - I am not up to speed with JSR-277 these days so that is good information. This makes a big difference for my long term outlook, even if I do like native OSGi. Your summary of the relationship between OSGi and Sun sounds like what I had imagined.

  4. Hani Suleiman Says:

    Karsten, JSR-277 is (sort of) that common ground. It attacks the problem from the JDK side, making life much easier for OSGi and other such solutions (maven, ivy, etc). Bundles/modules become first class citizens on the JVM level.

    Beyond that, it’s up to the framework (OSGi or whatever else) to provide any value-add stuff they want to. 277 does not limit that. The OSGi people just get upset that the standard baseline is not their implementation, and actually takes other things into consideration.

    In terms of the Hibernate analogy, imagine if JBoss kept attacking the JPA spec, saying it’s reinventing the wheel and everyone should just standardise on Hibernate instead. That’s what the OSGi people are doing.

  5. Peter Kriens Says:

    I am sorry that my technical analysis of the situation is perceived as ranting. Even after looking again I can not see any word that can be perceived as a rant?

    Anyway, I tried very hard to get into JSR 277 but was explicitly denied, even after the intervention from Doug Lea. After I wrote my review of the draft I was asked to help out but I could not become a member of the JSR 277 EG.

    I am still willing to work together, and I am advising some people in the group off line. Fortunately, they recently opened up their mailing list.

    The reason I have worked so long and hard on OSGi is because I feel the model of the platform with profiles is creating many different parallel Java worlds. The original dream of Java was write once, run anywhere. I still believe that is possible to create such an environment requires addressing some real modularity problems in a way that I strongly believe JSR 277 is not addressing. See the section in the OSGi spec about Require-Bundle, which is very similar to what JSR 277 will do.

    Fortunately, JSR 277 has stopped ignoring OSGi and has recently started addressing the interoperability issues between OSGi (and others) and JSR 277. I wish I could participate in those discussions.

    However, can you honestly say that if the JCP had been an independent organization that had looked at the interest of our industry, would JSR 277 have existed?

    Again, my intention is not to rant, nor to attack. I am a very technical oriented person and love to be proven wrong in a technical discussion because it means I have learned something. Can we have this technical discussion?

    Kind regards,

    Peter Kriens

  6. Chris Custine Says:

    Peter - I totally agree with you that had this been a purely technical issue, then Sun would have carried over the evolution and progress made with OSGi into the Java runtimes. But I do see their side in wanting a buffer between an externally controlled spec like OSGi and the Java platform. As a developer and user of both technologies, it certainly is good to hear that there is at least *some* behind the scenes collaboration going on.

    As far as ranting, that is part of what blogging is all about, and it has become part of the process in these sorts of things, so rant away! ;-)

  7. Peter Kriens Says:

    Well ranting and raving is rarely productive and definitely not my style.

    I think your last reply puzzles me a bit. There might be a business interest for Sun Inc. to control the language so they can leverage this with their licensing methods, but from a community point of view I fail to see the need for such a buffer? In contrast with JCP, the OSGi Alliance has no shepherd that plays with the sheep. Anybody can become a member, and each member has equal rights. Which would you prefer?

    In the end what counts is a good technical platform that addresses real needs of our community. The bottom line of one of the players should not play a role imho.

    Kind regards,

    Peter Kriens

  8. Chris Custine Says:

    Peter - I guess what I was thinking is that there are no controls to guarantee that the spec will not change outside of the “community” process, and that *may* be a reason for Sun’s obvious snubbing of OSGi. I know this is a naive and idealistic view of things, but that was part of my thought process in trying to rationalize Sun’s actions (trying to see both sides). I am not taking sides or anything, I was just trying to learn more about what is happening behind the scenes of this process, and I have certainly gotten some good information from people offline.

    For the record, I am an OSGi fan, and my project mates will vouch for that :-) I hope this situation will get better, but in the end I don’t think the new specs will move me to do anything other than native OSGi.

  9. Organic Element Blog » GlassFish v3 to be based on OSGi? Says:

    […] on Generated Sequence DiagramsAnjan Bacchu on Apache Directory Studio 1.0 for LDAPChris Custine on OSGi vs. SunPeter Kriens on OSGi vs. SunChris Custine on OSGi vs. […]

Leave a Comment