OSGi and JSR 277, Bad Vibes
The vibes that I am getting from JSR 277 are not very good. I have tried to contact Stanley Ho (the specification lead) several times over the last weeks but he plays deaf, awfully deaf. Maybe SUN should switch to other mail-servers? The Expert Group started end of June and was supposed to finish before September. It is now February and the information is deafening me. When I desperately tried to get into the JSR 277 Expert Group, Stanley Ho promised regular information updates. I still have to see the first.
The JSR 277 process shows clearly what is wrong with the JCP: too much secrecy and unchecked control by SUN. I know several participants in the Expert Group but they can not discuss matters with me due to the confidentiality clause in the contract with the JCP. Normally Non Disclosure Agreements are intended to prevent people from publishing information that needs to mature. In this case, however, there is genuine fear that they will be used if people tell me the ins and outs of this expert group. I understand the need for confidentiality in certain cases; in this case it is however abused. I fail to see why I could not sign an NDA to receive updates of the EG.
JSR 277 is a crucial JSR, one glance on the Mustang description shows that Java will collapse under its own weight unless it can be broken up in smaller chunks. I recall making a graph in ?97 about the exponential increase in packages in java between Java 1.0, 1.1, 1.2; it does not look like the rate has slowed down. Moore?s law has clearly saved Java from oblivion. However, the lack of dietary discipline has caused a huge split in the Java world: J2ME and J2SE, and not to forget the zillions of configuration profiles that exist today. I have participated on what is probably the most silly JSR ever: JSR 197. The only thing we did during more than a year was to allow javax.microedition to be used in J2SE environments, which is basically just a licensing issue. The mess Java has become could have been prevented (and can still be corrected) when all Java APIs are delivered as modules/bundles. Using OSGi (like) technology, the device/PC/server can download any module it requires to run. Believe me, the current model does not scale and is what I call a perfidox, a measure that achieves the opposite of its intention. Profiles were created to give developers stable environments by minimizing the number of configurations they have to program for. Talk to developers today, the world is too diverse for this. We need devices that can download the APIs they need.
At the OSGi Alliance, we have 8 years of experience in this area and tens of thousands of bundles have been created. We learned over 4 releases what worked and what did not work. The specifications ended up in tiny embedded computers with 8 Mb flash but we also run on mainframes with tens of gigabytes. Companies used for a single unique application while others had 10 million downloads in the last year. It is clear that the specifications have proven itself over time, something that is clearly reflected in the adoption rate.
From a technical point of view the OSGi specifications should be a godsend for Java; it takes time to get to such a mature specification. I am sure that the OSGi Alliance is willing to license the specifications at no cost; the OSGi Alliance is looking at adoption of OSGi/Java technology in as many devices as possible. Adoption by Java at large has always been the goal. So how is it possible that this potential marriage in heaven is not consumed?
I really have no clue.
posted by Peter @ Thursday, February 02, 2006