InfoQ

News

JSR 277 and JSR 291 Interoperability threatened by lack of a prototype

Posted by Rob Thornton on Sep 13, 2007 08:00 PM

Community
Java
Topics
JCP Standards,
Community
Tags
JCP,
OSGi,
JSR 277,
JSR 291

The latest salvo in the discussion of JSR 277, JSR 291, and OSGi appeared last week in the form of a post by Glyn Normington, spec lead for JSR 291 and Expert Group member for JSR 277. He is concerned that the Expert Group has not been presented with a strawman yet and that the Expert Group will end up merely rubber stamping the strawman rather than discussing it in detail and making changes.

Last week Normington and Bryan Atsatt (JSR 277 Expert Group member) wrote to the JSR mailing list inquiring about the status of the strawman and asking when it would be available for review. Stanley Ho, spec lead for JSR 277 replied stating:

The work is in progress, and there are ongoing prototypings to figure out how it should work and to also validate the overall approach. I will send out the strawman proposal for the EG to review and discuss when it is ready. Interoperability is definitely something that I would like to address before this JSR goes public review.

Normington is concerned about how 277 and 291 will integrate. He writes:

none of this is visible to the Expert Group or the broader community. This is a bit odd as a modules project has been set up on OpenJDK, so I would have expected that kind of prototyping to go on in a branch or subdirectory for early feedback from others.

It’s worrying because the OSGi experts, Richard Hall and myself, in the JSR 277 Expert Group and the others in the JSR 291 Expert Group are not currently able to help. By the time we see a strawman, it may be too late to make any significant changes.

Alex Miller weighs in, calling for the Java community as a whole to get more involved in this discussion due to the ramifications it will have for the platform.

If we do it right, it will support us and let us build the true Java equivalent of CPAN or Ruby Gems. If we do it wrong, it will make deployment and version management and JAR hell even worse than it is now. It’s crucial to get this right as it’s going to be baked deeply into our language, our libraries, and our tools.

Miller also calls on the Java Posse to take a more in depth look at the state of the JSRs. They have mentioned it a few times lately, and spurred some conversation on their discussion group. Neil Bartlett wonders if the strawman has been delayed because interoperability is a lot harder than Sun is letting on:

Will OSGi modules be able to interoperate cleanly with JSR 277 modules? I’ve been following the JSR 277 EG mailing list and it doesn’t look all that hopeful. At JavaOne the whole EG got together and Stanley Ho (the spec lead) promised to the EG that Sun would deliver a “strawman” design for interoperability. But they still haven’t come up with anything to share with the rest of the EG, and have refused to even let the other EG members participate in designing the strawman. My strong suspicion — and this is shared with others involved in OSGi — is that the two module system designs are just too different, and Sun are currently scratching their heads because they have no idea how to deliver the interop strawman.

For some history on the debate, you can refer to InfoQ’s earlier coverage.

3 comments

Reply

Some more thoughts by Alex Miller Posted Sep 14, 2007 5:52 AM
Errata by Ivo Danihelka Posted Sep 14, 2007 7:01 AM
Re: Errata by Rob Thornton Posted Sep 14, 2007 10:40 AM
  1. Back to top

    Some more thoughts

    Sep 14, 2007 5:52 AM by Alex Miller

    Thanks for giving this issue some more visibility guys! I wrote up some additional thoughts at my blog as well.

  2. Back to top

    Errata

    Sep 14, 2007 7:01 AM by Ivo Danihelka

    Stanley M. Ho is spec lead for JSR 277, not JSR 291.

  3. Back to top

    Re: Errata

    Sep 14, 2007 10:40 AM by Rob Thornton

    Oops. Thank you for catching that. I've updated the article.

Exclusive Content

Rob Windsor on WCF with REST, JSON and RSS

WCF is not just for SOAP based services and can be used with popular protocols like RSS, REST and JSON. Join Rob Windsor as he introduces WCF 3.5 and its new native support for non-SOAP services.

Christophe Coenraets Discusses Flex 3, AIR, and BlazeDS

Christophe Coenraets discusses Flex 3, Flex Builder, AIR, BlazeDS, Adobe and open source, integrating Flex with existing applications, and integrating RIAs with search engines and browsers.

Debunking Common Refactoring Misconceptions

Danijel Arsenovski attempts to dispel some of the myths around refactoring and how it applies to .NET developers.

REST Eye for the SOA Guy

In this presentation, recorded at QCon San Francisco, CORBA guru Steve Vinoski explains REST from the view of someone who comes to SOA from a traditional, RPC-oriented background.

Choose Feature Teams over Component Teams for Agility

Feature teams are key to scaling agility for large teams. In an excerpt from "Scaling Lean and Agile Development," Larman & Vodde show how feature teams resolve traditional problems & raise new issues

Billy Newport explains Virtualization

Billy Newport talks about virtualization, eXtreme Transaction Processing (XTP) and WebSphere Virtual Enterprise. He discusses hardware, hypervisor, JVM, application and data virtualization.

Virtualization and Security

While virtualization provides many benefits, security can not be a forgotten concept in its application.

Introduction to Agile for Traditional Project Managers

This session is specifically aimed at traditionally trained project managers who are new to Agile, and who would like to be able to relate the PMI's best practices to their Agile equivalents.