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 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:
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.
- David Bock
- Stuart Halloway
- Doug Lea
- Ted Neward
- Samuel Pullara
- Apache Software Foundation
- Ironflare AB
- SAS Institute Inc.
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?
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?
Reach for comment ...
- Stanley Ho
Re: Reach for comment ...
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 ...
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.
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.
discuss facts - not people
Re: discuss facts - not people
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...
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
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.
writing this instead.
Delivering Performance Under Schedule and Resource Pressure: Lessons Learned at Google and Microsoft
Ivan Filho Mar 06, 2014