Sun has opened up the mailing lists of JSR 277 for observers. As I am denied membership, I now can at least have the privilege of hearing the conversation in this group. And interesting it is. Last week there was a discussion about importing classes, modules, or packages. As I argued vehemently (too) many times, importing packages is better than importing modules because it decreases coupling to a minimum. Some JSR 277 members seem to feel similar and are pushing for a similar solution. However, I think Glyn Normington gave the right answer:

I like this idea! JSR 277's unique aspect is the repository. Repositories have a clear value and Java does not have one at the moment. Instead of trying to invent a vastly inferior modularity layer that will take years to mature, it would be so much better to use the existing OSGi technology standardized in JSR 291 instead. Modularity from 291, repository from 277, and a new keyword from 294, I would almost start looking forward to Java 7!

Which brings me to another point. Why actually needs a Java 7? I have just started using Java 5 in my daily work, though most of my customers force me to use 1.4 bytecodes. This week I installed Java 6 but I have not found a single item that interests me so far. I understand that in a non-modular system one has to rev the whole system, even if the updates to the parts of the system are minor. Major new VM releases are painful and the steady release of new Java environments are increasing the distance between J2ME and J2SE with every release. Making it harder and harder to run on all platforms.

The industry needs modular Java technology so that we can go back to achieving the goal of "write once, run anywhere". If Java 7 can bring us closer to that goal, I guess it is worth it. If not, then why bother?

Peter Kriens

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 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

Wow! I am very pleasantly surprised at the number of OSGi mentions at
JavaOne this year. OSGi was mentioned in the opening keynote by Sun when
discussion module systems for Java 7. It was also mentioned in the JSRs 277
and 294 sessions as well.

I attended a Java SE Embedded session where it was mentioned that OSGi was
being requested by a number of Java SE Embedded customers. Both Equinox and
ProSyst were specifically mentioned.

Peter Kriens and I just finished our OSGi Best Practices session which went
very well. We had 150+ attendees and loads of really good questions at the
end of the session. I hope to make the charts available online for you next
week.

Off to another session...