InfoQ

News

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

Posted by Rob Thornton on Sep 13, 2007

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

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.

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.

Educational Content

Brian Marick on 4 Challenges and 5 Guiding Values of Agile Software Development

Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).

Are You a Software Architect?

The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?

Agile – A Way of Life and Pragmatic Use of Authority

The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.

Getting Started with Grails, Second Edition

"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?

Using ITIL V3 as a Foundation for SOA Governance

Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.

Adrian Colyer on AspectJ, tc Server and dm Server

SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.

Adam Wiggins on Heroku

Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.

SOA as an Architectural Pattern: Best Practices in Software Architecture

For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.