'. '

EquinoxCompatibility

From APIDesign

(Difference between revisions)
Jump to: navigation, search
Line 3: Line 3:
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.
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!
-
That was naive expectation. It was more complex!
+
=== Functional Incompatibility ===
=== Functional Incompatibility ===

Revision as of 09:20, 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. I am using:

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

and this 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. This obviously complicates usage of such library due to increasing fear to upgrade. One needs to seek for a workaround (in my case I had to read the OSGi specification and adjust the code):

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


In spite of such workaround, this 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.

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!

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 by the amoeba effect.

Personal tools
buy