EquinoxCompatibility - Revision history

JaroslavTulach at 17:52, 14 July 2010

2010-07-14T17:52:54Z

←Older revision		Revision as of 17:52, 14 July 2010
Line 30:		Line 30:
	<comments/>		<comments/>

-	[[Talk:EquinoxCompatibility]]	+	{{:Talk:EquinoxCompatibility}}

JaroslavTulach at 06:45, 14 July 2010

2010-07-14T06:45:48Z

←Older revision		Revision as of 06:45, 14 July 2010
Line 29:		Line 29:

	<comments/>		<comments/>
		+
		+	[[Talk:EquinoxCompatibility]]

JaroslavTulach: /* Functional Incompatibility */

2010-07-13T21:13:33Z

Functional Incompatibility

←Older revision		Revision as of 21:13, 13 July 2010
Line 26:		Line 26:
	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/>

JaroslavTulach: /* Functional Incompatibility */

2010-07-13T21:10:42Z

Functional Incompatibility

←Older revision		Revision as of 21:10, 13 July 2010
Line 26:		Line 26:
	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/>

JaroslavTulach at 21:10, 13 July 2010

2010-07-13T21:10:07Z

←Older revision		Revision as of 21:10, 13 July 2010
Line 26:		Line 26:
	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/>

JaroslavTulach: /* Functional Incompatibility */

2010-07-13T09:29:23Z

Functional Incompatibility

←Older revision		Revision as of 09:29, 13 July 2010
Line 26:		Line 26:
	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]].
		+
		+	<comments/>

JaroslavTulach: /* Functional Incompatibility */

2010-07-13T09:28:25Z

Functional Incompatibility

←Older revision		Revision as of 09:28, 13 July 2010
Line 24:		Line 24:
	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]].

JaroslavTulach: /* Functional Incompatibility */

2010-07-13T09:24:57Z

Functional Incompatibility

←Older revision		Revision as of 09:24, 13 July 2010
Line 21:		Line 21:
	</source>		</source>

-		+	Now the code works in [[Felix]] and all versions of [[Equinox]] I am aware of.
-	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]].

JaroslavTulach: /* Functional Incompatibility */

2010-07-13T09:23:36Z

Functional Incompatibility

←Older revision		Revision as of 09:23, 13 July 2010
Line 15:		Line 15:
	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">

JaroslavTulach: /* Functional Incompatibility */

2010-07-13T09:23:17Z

Functional Incompatibility

←Older revision		Revision as of 09:23, 13 July 2010
Line 15:		Line 15:
	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">