JSR 232 Passed the Public Review Ballot

I just heard that the JSR 232 Expert Group has passed the public review ballot by the Executive Committee. The vote was overwhelmingly positive: In Favor 10, Against 0, Abstain 3, No Vote 3.

Congratulations to the JSR 232 EG and the OSGi MEG! Now, when do we get the JSR 232 phones? I want one!

Interestingly, Philips abstained with a comment that showed a mistaken understanding of the OSGi specifications:

On 2006-06-12 Philips Electronics UK Ltd voted Abstain with the following comment:
I am unable to vote in favour of this JSR due to technical concerns about OSGi. Specifically the requirement for all service bundles to run in the same VM instance. To freeze this in an architecture just as techniques for efficiently supporting multiple VM instances are appearing in products seems wrong.

I heard this story now several times as an argument against the OSGi so some elucidation is in place. The OSGi service model is very well suited for a multiple VM model but does not enforce distribution model on all applications because the performance overhead is pretty steep.

When we started with the OSGi Framework in 1999 we developed a prototype that was based on full isolation. The bundles communicated through communication pipes that required a specific protocol. After trying to start our third VM on the 486/32Mb machine we decided that scaling might be a tiny little blocking problem with this architecture. After lots of discussions, we decided that we wanted to isolate the bundles as much as possible but still run them in the same VM. The bundle communications were taking place through services. In OSGi speak, a service is a plain old Java object registered under an interface with the Framework.

So the OSGi model is very simple, if you want to communicate to any peers, you must obtain a service from the Framework or register a service with the Framework. All your communication therefore has to pass through a set of well known objects, objects which are tracked by the Framework.

In the current implementations, these objects are usually untouched by the Framework. This has the advantage of maximum speed and zero overhead, quite important in an embedded world. People have been telling me since 1981 that computers get cheaper and faster, but somehow, we the software people have always taken a significant bite out of that gain with easier programming models that are a lot less efficient. And as long as the average web site that has pages ending in .jsp feel slower than others, this efficiency gain seems not unimportant to the big guys as well.

However, there is nothing in the specification that forbids a Framework vendor to take advantage of multi VMs, as long as the methods in the service interface can be marshalled (serialized to transfer the parameters and return values to the other VM). Marshalling is not an OSGi specific mechanism, any multi-VM model will require it. Marshalling makes services implementations considerably harder and slower. A factor of 1000 to 10000 times slower is not uncommon. There is absolutely no free lunch here.

Within the OSGi model you have a choice. You can architect your system for maximum performance by running all bundles in the same VM. For most applications this is the best solution because the isolation that the OSGi model provides is sufficient, despite it is not 100%. Bundles that require a higher level of isolation can be moved to different VMs but suffer a performance bottleneck. So far, the isolation that the OSGi provides using the class loader model has proven to be sufficient, and for many applications the overhead of moving to a distributed model with higher isolation is just not worth it.

I hope that the Philips representative on the JCP EC will reconsider its judgment. Not only is better the enemy of good, in this case the OSGi Service Platform does not restrict the better in any way.