BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News JSR 277 and JSR 291 Interoperability threatened by lack of a prototype

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

This item in japanese

Bookmarks

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.

Rate this Article

Adoption
Style

BT