EquinoxCompatibility
From APIDesign
(→Functional Incompatibility) |
|||
| (14 intermediate revisions not shown.) | |||
| Line 1: | Line 1: | ||
The [[Netbinox]] project (which provides the [[NetbinoxPerformance|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. | The [[Netbinox]] project (which provides the [[NetbinoxPerformance|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 | + | 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 === | === Functional Incompatibility === | ||
| - | My code needs to find out all packages in each bundle. I | + | My code needs to find out all packages in each bundle to optimize classloading. I started to use |
<source lang="java"> | <source lang="java"> | ||
| Line 11: | Line 13: | ||
</source> | </source> | ||
| - | and | + | 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. | + | 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): |
<source lang="java"> | <source lang="java"> | ||
| Line 19: | Line 21: | ||
</source> | </source> | ||
| + | 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! | ||
| - | In | + | 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|amoeba effect]]. In today's email conversation [[Richard Hall]] 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 its previous release too. And the [[Amoeba]] is shaking and shaking... |
| - | + | <comments/> | |
| - | + | {{:Talk:EquinoxCompatibility}} | |
Current revision
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!
Contents |
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 Richard Hall 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 its previous release too. And the Amoeba is shaking and shaking...
<comments/>
Richard S. Hall said ...
I guess you are right (although there is always way to provide AlternativeBehaviors), it is better to follow the spec (especially if the TCK is improved to cover the case). On the other hand, this is not true containerism: the (mis)behavior was the same in Equinox 3.5 as well as in Felix. Otherwise I would find out I need to pass in null sooner.
--JaroslavTulach 18:03, 14 July 2010 (UTC)
Richard S. Hall said ...
Yeah, it was unfortunate that there was a similar issue in both. I've added a test case for this for Felix at least, but one should probably be added to the OSGi CT too.
--Richard S. Hall 20:10, 14 July 2010 (CEST)
Prakrathi said ...
That is completely unbalstendadre.I've been contemplating doing this as well, but was wondering how you approached those specific hurdles.I'm not a lawyer, but the OPC specs are published under the RCL (never heard of it) but it states under the RCL your changes, bug fixes, extensions, etc. must be made available to the community. I figure the term community ties the source and changes back to foundation members.If we do tackle this, I would hope to make it official (as Utgard is on the OPC website) but also be able to keep it open-source.Thank you for your feedback!
--Prakrathi 08:29, 21 October 2013 (CEST)
Dewi said ...
Forcing users to get a pay tool to do what a different open soucre tool does is not a strategty that will win long term. We want people writing snazy code, and we want it in eclipse right? SWT designer is nice, my team purchased it. But it doesn't beat Matisse, and it's a glaring failure of Eclpse as a whole.Asking users to buy a book (even the Eclipse RCP book) doesn't seem like a good strategy either. It's not that the documentation isn't out there, it's that it seems to have been written bya bunch of fuedal lords, none of whom care to share their technology with each other and make a aactual real integrated tool and documentation set out of it.I have looked at Eclipse Riena, and I like lots of it, but once again, how does this technology mix and match with everything else? Not well it seems.
--Dewi 02:44, 22 October 2013 (CEST)
Follow
I'm not a believer in being backwards compatible with bugs, otherwise there'd be no end. The spec is the law of the land in the OSGi world, so that's what bundles should expect to get. If we weren't strict with that, then bundles would continue to depend on containerisms even after they were corrected.
--Richard S. Hall 03:50, 14 July 2010 (CEST)