[EMAIL PROTECTED] wrote on 2007-07-25 15:00:33:
> All,
>
> I am running into a version compatibility issue that worries me.
> Although I will describe this in terms of the Equinox implementation,
> I think it is a general OSGi issue.
>
> I have a utility class that combines the OSGi StartLevel service with
> a service tracker so that you can simply make the start level calls to
> it, and the implementation does the work of checking for and
> dereferencing the service (throwing suitable exceptions on failure).
>
> It is declared thus:
>
> ----
> public class StartLevelTracker
> extends ServiceTracker
> implements StartLevel {
> }
> ----
>
> I wrote the implementation in/on Eclipse 3.2 whose underlying OSGi
> framework is R4.
>
> When I downloaded and moved to Eclipse 3.3 whose underlying OSGi
> framework is R4.1, this utility class no longer compiles.
>
> Between version 1.0 of the StartLevel service package and version
> 1.1, the start level service has the new method
> isBundleActivationPolicyUsed(Bundle bundle).
>
> Of course my implementation of this interface lacks the new method
> and does not compile.
>
> The crux of my question: Doesn't the addition of a method to an
> interface break backwards compatibility?
It does for implementors of the interface but not for users of the
interface.
The StartLevel interface is meant to be implemented by the framework and
used by bundles. Since this interface is predominantly *used* and not
implemented, OSGi has and will add new methods to it from time to time as
needed. Only the framework implementation are affected. However, you are
"acting" as a framework implementation as well as using the interface and
have thus been affected.
Backwards compatibility depends upon the perspective of the party. For
interfaces which OSGi intends will be implemented by bundles (e.g.
EventHandler), we will not add methods (without perhaps a major version
number increase) since that will affect bundle code. But for interfaces
which are intended only to be used by bundle code and implemented by the
framework (e.g. Bundle, StartLevel), we will add methods without bumping
the major version.
>
> It is my impression that the semantics of OSGi versions is that code
> should be backwards-compatible through major versions. We write all
> our dependencies as "[a.b.c,a+1.0.0)" e.g. "[1.2.3,2.0.0)". This
> particular change appears to break backwards compatibility on that
> package while only incrementing the minor version. Should we only
> rely on compatibility within minor versions? If so, won't that
> increase the likelihood of wiring issues across many bundles?
>
> Or, put another way, does implementing an interface from an exported
> package tie you to a very narrow version range, and if so, should
> this be avoided?
>
> Additionally, this issue is magnified when Require-Bundle is brought
> in. I know that the OSGi position is that Import-Package should be
> used to create loosely-coupled systems. However Eclipse continues to
> provide much/most of its architecture using Require-Bundle, with more
> projects springing up all the time. As an engineer developing
> bundles that use third-party bundles of both philosophies, I am
> starting to encounter wiring problems as our systems pass the "Hello,
> World" scale...our runtimes have literally hundreds of bundles.
>
> Thanks in advance.
>
> /djk
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> http://www2.osgi.org/mailman/listinfo/osgi-dev
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
office: +1 386 848 1781
mobile: +1 386 848 3788
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
