Java Component War?
Inspired by Donald’s post I am going to use a combination of wild hyperbole and question marks in my blog titles for a while.
Last December Onno Kluyt kindly asked if I would come and talk about Eclipse at the JCP’s Executive Committee meeting. The last point in my presentation was “JSR277 is just weird“. Apparently Peter Kriens feels the same way.
Peter has done a great job describing the technical limitations of the JSR. My concerns are related but different. It seems pretty obvious that JSR 277 exists to take some of the wind out of OSGi‘s momentum, and to ensure that the core component architecture used by Java applications is written by Sun. To even further muddy the waters, there exists JSR291, which is basically going to but a JCP stamp on the existing OSGi standard.
The problem as I see it is that whenever JSR277 sees the light of day it is going to be built into the core of JSE. This will likely happen two or three years down the road. In the meantime, OSGi exists today and there are tons of companies who are currently making large investments in products and applications built on top of Eclipse Equinox, Apache Felix, ObjectWeb Oscar, GateSpace’s Knoplerfish, or ProSyst to name just the OSGi implementations I know of off the top of my head.
When a version of the JSE ships which has an inferior and incompatible component architecture in it, it is going to be one heck of a train wreck. The combination of NIH with too little, too late is not a good one. My guess is this could end up making the JDO/EJB/POJO persistence battles of recent memory look like a pillow fight by comparison. Which is really too bad. Simply adopting OSGi R4 for JSE would have been such a bold and unifying move.