JSR 291 (OSGi 4.1) Is Accepted by the Executive Committee
2007-05-22
As of yesterday May 21, 2007, JSR 291 has been approved. The Executive Committee has approved the OSGi R4.1 specification! I'd like to congratulate Glyn Normington for running this JSR in an exemplary way. It is really good to see that the JCP, in the end, can accept outside technology and bring it under the Java technology umbrella.
Unfortunately, not all EC members voted in favor. Only Sun and Hani Suleiman voted against for an apparent allergy to rubber (stamping). Let us take a look at their comments:
I can now rant about that fact that the OSGi Alliance updated the specification to version 4.1 based upon the JSR 291 EG requirements, and that these rubber stamping issues have been addressed by the specification lead ad nauseum on the mailing list, without receiving any reply from Sun. However, that is completely besides the point. The crucial question that arises from their comments is: Why on earth should rubber stamping be wrong?
To me, the integration of an external, mature standard in the Java world sounds like a perfect time & money saver. And I do not mean the hours saved by the JSR 291 Expert Group by having a solid document and existing implementations. Those hours are minor. I mean the hours saved by the end users because they do not have to waste endless hours trying to use immature specifications that not infrequently have to be overhauled. Any serious Java user can surely recall several JSRs where version 1 and 2 were not really that usable in practice. J2EE comes to mind? Obviously, Java users can only gain when the JCP adopts mature technology. Several key Executive Committee members voiced this sentiment in their comments as well.
Sun's statement shows a troubling disconnect between them and the interest of the Java community. We, as a community, need standards to minimize our work and maximize the quality of our products. We need standards so that for a given problem there is a shared industry wide API so we can be assured that our investments in these APIs are secure. We need standards so we can choose between different implementations, which will reduce the price and increase quality. We do not need standards to keep Expert Groups on remedial therapy. The advantage of a adopting a pre-existing standard is so blatantly obvious that one can only wonder what Sun's motives are. They are clearly not in the interest of our industry.
This disconnect is bad for our industry, and it is obviously upsetting for the OSGi members, adopters, and myself. Our attitude to standards has always been very much to adopt instead of develop. The IO Connector Service, the URL Stream Handler Service, the XML Parsing Service, the OMA DM management interface, and even the whole security model have been designed to work seamlessly with Java and anything that comes from the JCP. For R3, there was a strong push to design a brand new messaging service but after ample considerations we developed the IO Connection service that relies on the
To conclude: JSR 291 has been approved and that is good. Sun's comments are upsetting but fortunately not serious because the other EC members voted yes. However, down the pipeline we see the Modularity JSR 277 coming, which is almost a full subset of OSGi technology, and thus JSRs 291 and 232. Is this good for our industry or is this another case where Sun is confused about the needs of our industry?
Peter Kriens
Unfortunately, not all EC members voted in favor. Only Sun and Hani Suleiman voted against for an apparent allergy to rubber (stamping). Let us take a look at their comments:
On 2007-05-15 Sun Microsystems, Inc. voted No with the following comment:
Sun's vote is not a negative assessment of the OSGi specification or technology, but rather on the purpose of this JSR and expert group when the specification exists and is being actively developed elsewhere.
The JSR 291 specification is simply a reference to the OSGi Core spec version r4. No other specification work has been created in the context of the JCP JSR 291 expert group. Rather the work to update the r4 spec occurred in the OSGi working group.
This manner of working contradicts the goals of the JCP to create expert groups empowered to evolve Java technology with the freedom to make design choices and technical decisions based on the needs of the Java Community. Sun has consistently expressed these concerns, as have other community members, throughout the lifetime of the JSR as our previous voting comments show.
Since these concerns been not addressed by the spec lead, either at the inception ballot or at the public review ballot, we are reluctantly voting no.
Sun's vote is not a negative assessment of the OSGi specification or technology, but rather on the purpose of this JSR and expert group when the specification exists and is being actively developed elsewhere.
The JSR 291 specification is simply a reference to the OSGi Core spec version r4. No other specification work has been created in the context of the JCP JSR 291 expert group. Rather the work to update the r4 spec occurred in the OSGi working group.
This manner of working contradicts the goals of the JCP to create expert groups empowered to evolve Java technology with the freedom to make design choices and technical decisions based on the needs of the Java Community. Sun has consistently expressed these concerns, as have other community members, throughout the lifetime of the JSR as our previous voting comments show.
Since these concerns been not addressed by the spec lead, either at the inception ballot or at the public review ballot, we are reluctantly voting no.
I can now rant about that fact that the OSGi Alliance updated the specification to version 4.1 based upon the JSR 291 EG requirements, and that these rubber stamping issues have been addressed by the specification lead ad nauseum on the mailing list, without receiving any reply from Sun. However, that is completely besides the point. The crucial question that arises from their comments is: Why on earth should rubber stamping be wrong?
To me, the integration of an external, mature standard in the Java world sounds like a perfect time & money saver. And I do not mean the hours saved by the JSR 291 Expert Group by having a solid document and existing implementations. Those hours are minor. I mean the hours saved by the end users because they do not have to waste endless hours trying to use immature specifications that not infrequently have to be overhauled. Any serious Java user can surely recall several JSRs where version 1 and 2 were not really that usable in practice. J2EE comes to mind? Obviously, Java users can only gain when the JCP adopts mature technology. Several key Executive Committee members voiced this sentiment in their comments as well.
Sun's statement shows a troubling disconnect between them and the interest of the Java community. We, as a community, need standards to minimize our work and maximize the quality of our products. We need standards so that for a given problem there is a shared industry wide API so we can be assured that our investments in these APIs are secure. We need standards so we can choose between different implementations, which will reduce the price and increase quality. We do not need standards to keep Expert Groups on remedial therapy. The advantage of a adopting a pre-existing standard is so blatantly obvious that one can only wonder what Sun's motives are. They are clearly not in the interest of our industry.
This disconnect is bad for our industry, and it is obviously upsetting for the OSGi members, adopters, and myself. Our attitude to standards has always been very much to adopt instead of develop. The IO Connector Service, the URL Stream Handler Service, the XML Parsing Service, the OMA DM management interface, and even the whole security model have been designed to work seamlessly with Java and anything that comes from the JCP. For R3, there was a strong push to design a brand new messaging service but after ample considerations we developed the IO Connection service that relies on the
javax.microedition.io API. It has been our clear philosophy to only add a standard that fulfilled an unfulfilled need. And, if we did, provide a high quality specification. The standards landscape is already polluted enough as it is. Nobody is waiting for new standards unless it provides significant new value.To conclude: JSR 291 has been approved and that is good. Sun's comments are upsetting but fortunately not serious because the other EC members voted yes. However, down the pipeline we see the Modularity JSR 277 coming, which is almost a full subset of OSGi technology, and thus JSRs 291 and 232. Is this good for our industry or is this another case where Sun is confused about the needs of our industry?
Peter Kriens
Add a comment