EquinoxCompatibility

From APIDesign

Revision as of 21:10, 13 July 2010

The Netbinox project (which provides the fastest OSGi container on the Earth for launching desktop applications) is based on top of Equinox. Originally I started with Equinox version 3.5, but recently some customers requested an upgrade to the newly released 3.5.2 version.

I am not doing any non-API tricks while using Equinox. I rely either on OSGi interfaces or Equinox extension hooks. No reflection, no access to implementation details, etc. As such I was expecting the upgrade to be as easy as dropping new version of equinox.jar into the system.

That was naive expectation. It was significantly more complex!

Functional Incompatibility

My code needs to find out all packages in each bundle to optimize classloading. I started to use

Enumeration en = bundle.findEntries("", "", true);

and such code works quite fine with Felix and Equinox 3.5. However it does not work at all in Equinox 3.5.2!

What that implies? Well, the Equinox implementation is shaking like an amoeba. In one release something works, in other it does not. Shakes like this obviously complicate usage of such libraries due to increasing fear to upgrade. Upgradability is no longer guaranteed, it is associated with problems and additional tweaks. One needs to seek for a workaround (in my case I had to re-read the OSGi specification and adjust the code):

Enumeration en = bundle.findEntries("", null, true);

Now the code works in Felix and all versions of Equinox I am aware of. In spite of the workaround, there still remains a BackwardCompatibility problem in Equinox. Something that used to work (in old version and also different implementation of the same API) no longer works in newer versions.

One can pretend that this is not a problem - e.g. the OSGi specification does not prescribe behavior of empty string being passed in as second parameter. An answer like: you have not read the specification properly, would then be appropriate. But hey, I am clueless user of the API! It is not my job to read specs, it is my job to get my code run! And it used to run. Even on two different implementations!

One can also admit that this is a problem. In such case there shall be new test, preferably in a TCK, to ensure Equinox is not vulnerable to the amoeba effect. In today's email conversation RichardHall confirmed that the spec seems to indicate empty string shall match nothing. Richard reported himself a bug, so next release of Felix will be functionally incompatible with it previous release too. And the Amoeba is shaking and shaking...

<comments/>