EquinoxCompatibility
From APIDesign
(→Functional Incompatibility) |
(→Functional Incompatibility) |
||
Line 7: | Line 7: | ||
=== Functional Incompatibility === | === Functional Incompatibility === | ||
- | My code needs to find out all packages in each bundle to optimize classloading. I | + | My code needs to find out all packages in each bundle to optimize classloading. I was using: |
<source lang="java"> | <source lang="java"> |
Revision as of 09:21, 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 was 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.