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

JSR 277 is a Sun-led group defining a de-jure Java^TM 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?