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.
Life at Eclipse 
For me, this is a test of the JCP process. If OSGi is ignored and something else embraced (perhaps based on the NetBeans module system?), then it will be a clear signal that the JCP is a farce.Steve
Steve
October 22, 2006 at 8:29 am
To play devil’s advocate here… it is quite possible that there is a component framework that they could design/develop/choose that would be more suited to what they want to do and isn’t OSGi.Chances are if they go with OSGi they may need some custom enhancements/changes, and will have to wait on the OSGi standards body, or be cruicifed for using a non-standard version of OSGi.
RefuX
October 22, 2006 at 2:37 pm
Steve – The JSR 277 early draft is already out, and if I understand Peter’s blog entry it is “something else”. But I haven’t heard anything about it being tied to the NetBeans module system. Has anyone actually compared NB vs. 277 to look for any similarities?
Mike Milinkovich
October 22, 2006 at 5:01 pm
Refux – what you say might be true. But the cost to the Java community and ecosystem of them going down this path is awfully high.
Mike Milinkovich
October 22, 2006 at 5:04 pm
Refux, it is quite possible that OSGi is missing features that they need but Peter doesn’t seem to think so.Mike, Peter should do the comparison. If it’s the same, that would look really bad.Steve
Steve
October 23, 2006 at 11:27 am
JSR 277 is -not- based on the netbeans module system. Notice that the scope of 277 is very small. The work is completely new.The key problem is lack of requirements. If 277 and 294 had done a proper requirements analysis we, and others, could have responded with our strentgths, weaknesses and opportunities to improve. This is the process we followed for Eclipse 3.0, I was part of the team that compared all the appropriate standards and in the end the OSGi specs were found to be the best match.We are currently in JSR 291 discussing other requirements, it is not a rubber stamping process. We have members and users that have real world needs that we want solved. If we miss crucial features that are crucial, within our scope than the OSGi has no qualms adding those. If you want to push changes, join the organization! We can not refuse a company from becoming a member, actually, we would highly welcome more participation. Peter Kriens
Peter
October 28, 2006 at 10:27 am