BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Sun's Silence on JSR 277 Leaves Many Questions from OSGi Supporters and Few Answers

Sun's Silence on JSR 277 Leaves Many Questions from OSGi Supporters and Few Answers

This item in japanese

Bookmarks

JSR 277 is a Sun-led group defining a de-jure JavaTM Module System. It has been active since June 2005, and delivered an early draft review in November 2006. Given that its stated intent is to be part of J2SE 7.0 (Dolphin), there's some way to go before it is going live. Fortunately for JSR 277, Dolphin seems to be delayed into 2009, from a discussion on today.java.net:

Open sourcing Java and creating the OpenJDK infrastructure has apparently taken quite a bit of work for Sun, and this brings us to the bad news. Sun typically aims to release new versions of Java at 18-month intervals. Java 6 was released in fall 2006. The original Java 7 schedule, therefore, called for a release in spring 2008. Given that the current builds available from the JDK7 project have integrated no major new features, we obviously aren't even close to a beta release. Danny Coward, who will be the spec lead for the Java 7 JSR, now says that they're aiming for a release in January 2009, about 16 months from now.

OSGi, or JSR 291, is a module system for Java that has almost a decade of use. There are a number of commercial and freely available implementations (Felix, Knopflerfish, Equinox). Unlike JSR 277's dependence on Java 7, OSGi implementations run from Java 1.3 and the J2ME Foundation profile. Many systems use OSGi internally already, and ensuring that OSGi and JSR 277 work together is a requirement for JSR 277 to succeed.

The JSR 277 expert group consists of a number of key players in the Java ecosystem; Apache, Google, Red Hat, BEA etc. Several of them have experience in existing module systems for Java; Richard Hall is the creator of Felix and IBM's representative works on Equinox. Despite that strong expert group, there doesn't seem to be much discussion happening on the publicly readable mailing list; the implementation is being done at openjdk.java.net and a different mailing list modules-dev, which is a mixture of discussions and automated bug report reports.

There has been some questions as to whether the JSR is running smoothly. Dalibor Topic asked in January:

I'd also like to propose replacing the inactive portion of the members of the apparently dormant EGs on JSR 277 by people who seem to care about the JSRs in question, namely:

  • David Bock
  • Stuart Halloway
  • Doug Lea
  • Ted Neward
  • Samuel Pullara
  • Apache Software Foundation
  • Ironflare AB
  • Jayasoft
  • SAS Institute Inc.
As they have not managed to post a single message to the expert group's mailing list since last May (in words: 8 months), so I think they can be safely gc-ed.

 

I am sure the spec lead could easily find interested experts with a more active interest in the subject, for example among the readership of this mailing list.

Dalibor's point is well made; there are a number of people on the JSR 277 expert group who haven't chimed in (although SAP have in fact commented more recently than May). What's perhaps more concerning is the fact that the Expert Group aren't being asked to comment about the developments of the module system itself. Instead, the design is evolving by documenting an implementation.

The proposed compatibility with OGSi is still as far off as ever. Last June, a question was posted on the JSR 277 expert group list asking for the status of OSGi interoperation. The same question has been asked since, and the Expert Group hasn't been given any implementation that is close to being compatible or even have a strawman available. In the most recent posting to the expert group, Stanley Ho says:

Interoperability with other module systems: As we discussed in the EG, we would like to make JSR 277 interoperable with other module systems (e.g. OSGi, NetBeans, etc.). There have been ongoing prototypings to figure out how it should work and to also validate the overall approach. When the strawman proposal is ready, I will send it out for the EG to review and discuss. Interoperability is definitely something that I would like to address before this JSR goes public review.

It remains to be seen whether JSR 277 will be JSR 291 compliant or not; at the moment, it isn't. If the rate of progress remains the same as it has done over the previous year, then it won't be ready in time for inclusion in Dolphin's release at the start of next year. In the meantime, questions about the JSR 277 process remain: Peter Kriens asks if it would be different if Java was shepherded in a more neutral way:

I wish we could focus on the technical issues so we can show why and how the OSGi service platform is more ambitious and provides more and superior solutions for the modularity problem than JSR 277+294. It feels so sad that instead on working together on a suitable standard, Sun, against a lot of industry pressure, bifurcates the market for no technical reason. I do not claim the OSGi specs are perfect, there is work to do. However, they are mature, proven, have a large audience, and seem to provide more functionality than JSR 277 attempts to implement now (with a large learning curve ahead of them). Would such a situation have arisen when the Java community was shepherded in an more independent way?

whilst Neil Bartlett asks whether the problem lies with the spec lead:

So, after nearly a year the strawman is still "in progress", with no indication of how much progress has been made and how much is still needed. Sun is clearly still doing something, because there is endless activity being logged against the modules-dev component of OpenJDK. But they don't feel like asking the JSR 277 expert group ” in theory, the world's foremost experts on module systems in general and OSGi in particular ” for their opinions or their help.

In January, Dalibor Topic proposed running a GC cycle over the JSR 277 expert group members, many of whom have been shamefully inactive. I quite agree. Let's start with the spec lead.

InfoQ was unable to reach Stanley Ho for comment. What do you think? Should JSR 277 be OSGi compatible?

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Reach for comment ...

    by Stanley Ho,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Alex was actually able to reach me but I asked for a day or two to give him the comments. I was very surprised to see it published anyway without waiting for the comments to provide a balanced view. Alex, I will still send you my comments shortly as I mentioned.

    - Stanley Ho

  • Re: Reach for comment ...

    by Neil Bartlett,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Stanley, would it be too uncharitable for me to speculate that your reply to Alex was:


    I am out of the office at the moment with limited access to email. I will deal with your query when I return.


    since this does appear to be your standard way of dealing with inconvenient questions, even those from your colleagues on the Expert Group.



    However, I am heartened to see your email to the EG this morning that the interop strawman is almost ready for review. I look forward to reading it.

  • Re: Reach for comment ...

    by Alex Blewitt,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    My apologies - Stanley did reach out to me and gave this comment after the article was posted:

    We would definitely like to make it possible for JSR 277 to interoperate with other module systems, e.g. OSGi. We have been building prototypings to figure out how it should work and to also validate the overall approach. Since there are many module systems out there and they are all implemented differently (there are also multiple OSGi implementations), it requires us to build more than a few prototypes and the whole process takes time. The good news is that we already have a prototype that interoperate with OSGi in certain degrees, and we're in the process of sorting out the details so we could have a strawman for the EG discussion soon.



    Let's hope that the JSR 277 EG get to see this proposal and comment soon. Fortunately, although there are multiple OSGi implementations, they all implement the same OSGi interface so testing against each one shouldn't be necessary.



  • FUD?

    by Gavin Terrill,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Since there are many module systems out there and they are all implemented differently (there are also multiple OSGi implementations)

    Having multiple implementations of the same interface is a completely separate idea than having many module systems. It is disconcerting to think that a spec lead would confuse these things.



    In any case, I'm with Dalibor. 277 is DOA. Get over it. Move on. Nothing to see here.

  • Re: FUD?

    by Neil Bartlett,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I agree that this is a little bit of FUD. It's also completely irrelevant... there's absolutely no need for them to test thoroughly against all of those implementations before allowing the Expert Group to get involved at all. In fact the EG are precisely the people who could have helped them get the job done more quickly.

  • discuss facts - not people

    by Gerald Loeffler,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    there is a well-tried approach to reconciling differences: discuss facts - and discuss them as passionately as you like - but don't discuss people. maybe the camps in this debate should give this a try for once - it's good for you. and it's good for the great majority of the Java community who are not really so terribly excited by all this but just want a well-engineered Java module system, no more, no less...

    regards,
    gerald

    www.gerald-loeffler.net

  • Re: discuss facts - not people

    by Rob Bygrave,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    True enough Gerald... but it appears to some observers as though politics is at play and progress has been suprisingly slow given that OSGi represents a mature and widely adopted solution to "model" off or even adopt entirely.



    My guess is that many people see a module system as being VERY important and are getting edgy because they think it is getting screwed up by political rather than technical factors. The community is looking for some assurances from the people involved, hence the direct questions.



    My questions are:

    Q: What are the other module systems? NetBeans and ... ?

    Q: How mature are they relative to OSGi?

    Q: Why shouldn't we just adopted OSGi?

  • Some parts of the spec request should be updated...

    by Tomas Kysela,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    ... to reflect the actual situation. Especially those part explaining why the issue is not alreay solved by other specifications:


    The R3 version of the Open Services Gateway Initiative (OSGi) specification defines a framework that enables the deployment of service-oriented applications (called bundles). However, the framework only supports package dependency based on the minimum version of a specification, and there is no support for exact version or version range. The framework also supports package dependency based on an implementation, but there is no support for versioning. Moreover, the framework must choose one bundle that will be the provider of the exported package for all bundles which have dependencies on that package, so it is impossible to support more than one version of shared package at runtime. Besides, the selection of exported package provider is anonymous, and there is no way to influence the selection. Because the versioning semantics in the OSGi R3 framework is simplistic, it is not a sufficient solution to address the JAR referencing problem.



    There is already R4 OSGi spec out and the arguments about versioning are no longer true. Lets first look what is already there (I assume spec leads are professionals, not suffering from not invented here syndrom) and lets decide if building something new from the scratch will add relevant amount of value. If yes, please provide a better description based on actual arguments, if not, let's get OSGi in Java 7 official and lets move on.

  • Re: discuss facts - not people

    by Neil Bartlett,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Gerald, I agree. It occurs to me that my comment about firing the spec lead might have been misinterpreted. The spec lead on this JSR is Sun Microsystems, not Stanley Ho.



    To pass JSR 277 the way Sun management wanted it would have required a stellar diplomat and negotiator. Stanley was not the guy to do it, but very few others could have pulled it off either.

  • Some thoughts

    by Bryan Atsatt,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Great article, Alex. I spent a bunch of time composing a reply, then decided it was way too long. Ended up
    writing this
    instead.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT