Bindings, Platforms, and Innovation
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
Tracking change and innovation in the enterprise software development community
Posted by Rob Thornton on Sep 13, 2007 08:00 PM
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.
Download the Free Adobe® Flex® Builder 3 Trial
Adobe® Rich Internet Application Project Portal
SOAsocial.com - See what the SOA community is Talking About
Thanks for giving this issue some more visibility guys! I wrote up some additional thoughts at my blog as well.
Stanley M. Ho is spec lead for JSR 277, not JSR 291.
Oops. Thank you for catching that. I've updated the article.
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.
This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.
This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.
This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.
After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.
IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.
Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.
3 comments
Watch Thread Reply