The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Rob Thornton on Sep 13, 2007
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.
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
Improve Java Garbage Collection, Runtime Execution, and JVM visibility with Zing
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
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.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.
Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
3 comments
Watch Thread Reply