EquinoxCompatibility
From APIDesign
(→Functional Incompatibility) |
(→Functional Incompatibility) |
||
| Line 13: | Line 13: | ||
and this code works quite fine with [[Felix]] and [[Equinox]] 3.5. However it does not work at all in [[Equinox]] 3.5.2! | 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 [[ | + | 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): |
<source lang="java"> | <source lang="java"> | ||
| Line 24: | Line 24: | ||
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 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 [[ | + | 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|amoeba effect]]. |
Revision as of 09:18, 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. It was not!
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.
Follow
