I checked out the OSGi presentation from the Parleys site http://www.bejug.org/confluenceBeJUG/display/PARLEYS/Spring+OSGi. Wow. I haven’t really spent any time thinking about this stuff in the past, but it seems that yet again the JSR process is trying to formalize something that doesn’t need it. OSGi seems to be a much lighter, more powerful model whereby you can switch bundles, the JSR-277 module equivalents, at runtime via an OSGi console or JMX. Check out http://www.osgi.org and http://en.wikipedia.org/wiki/OSGi for good synopses of the technology and what it can offer.
The huge advantage here is that the technology is stable, mature and available to use right now (there are a number of open-source implementations) rather than needing to wait for something that won’t be around until Java 7. All that and no new language structures.
There’s an interesting post by Peter Kriens from OSGi about how JSR-277 stacks up at
http://www.osgi.org/blog/2006/10/jsr-277-review.html
"The ambition level of JSR 277 is significantly lower than where the OSGi specifications are today, even way lower than we set out in 1998. In a way, for me the JSR 277 proposal feels rather toyish. "
It’s time to kick the tires on this one, and see where it might be useful.
Comments
2 responses to “OSGi vs. JSR-277”
I have to say, I agree with this opinion too.
But it need not be limited to the current Eclipse or SWT background; I’m giving a presentation on dynamic OSGi applications with Swing at JSig in London, UK on February 15th 2007. It’s not close to Dublin, but we’ll make the presentations and source available afterwards.
Alex.
BeJUG posted 3 talks on versioning: OSGi, JSR-277 and a talk that puts those two in context and tells what is still missing. That talk is by Alex Krapf on “Scaling over time – the versioning problem” check it out on Parleys.com … really interesting stuff !! He suggests to make versioning a first class citizen in the Java language !
Enjoy
-Stephan