<comments/>

<comments/>

[[Talk:EquinoxCompatibility]]

{{:Talk:EquinoxCompatibility}}

<comments/>

<comments/>

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 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|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 it previous release too. And the [[Amoeba]] is shaking and shaking...

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/>

<comments/>

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 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|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...

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 it previous release too. And the [[Amoeba]] is shaking and shaking...

<comments/>

<comments/>

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 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|amoeba effect]].

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 [[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/>

<comments/>

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

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 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.

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!

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

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]].

</source>

</source>

 

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.

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!

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|amoeba effect]].

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]].

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

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 not 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):

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">

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

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. 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):

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 not 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">