JCP “rubberstamping” and Eclipse.org project disarray?
So JSR #291 (Dynamic Component Support for Java), a.k.a. OSGi R4, has been approved. It is interesting to read the concerns expressed in SE Executive Committee’s voting comments. There is a huge overlap with the work that is being done under JSR #277 – that project looks kind of dead in the water now. Exactly how the JCP SE/EE can allow two competing module specifications to evolve is beyond me but it happened so it would seem the JCP is now broken. That said, JCP cannot expect to write every new specification from scratch and even not meddling with de-facto specifications (e.g. DOM) is also ocassionally appropriate.
Unfortunately, Eclipse.org is also starting to exhibit similar cracks. A cursory look at the architectures of many of the top level projects (WTP, STP, TPTP, BIRT etc.) shows the lack of intra-project cooperation is resulting in frameworks that simply don’t integrate with one another in they ways we all want them to. I’m not sure whether the PMCs are responsible for this failure or if it is also the committer’s responsibility to “fit in” to the larger Eclipse eco-system better.
The end result is a selection of overlapping frameworks (and derived vertical commercial products) that will not peacefully co-exist on a single Eclipse runtime or integrate in any meaningful manner. So much for re-usability. Of course Eclipse.org are trying to get their release processes in order (and I hope that effort works out) but architectural inconsistencies and overlaps in the platforms is a much larger and deeper rooted problem altogether.
Recent Comments