Java Reference
In-Depth Information
DOWNSIDES AND PITFALLS
The recommended OSG i versioning policy sounds good, and it's been used success-
fully by many projects. But new users should still take care due to a subtlety regard-
ing the use of Java interfaces, which is related to whether an interface is being used
or implemented.
The difference seems trivial, but it becomes important in the context of version-
ing. Consider the following 1.0.0 version of the Foo interface:
public interface Foo {
Bar getBar();
}
What happens if you change this simple interface? For example, suppose you add a
method:
public interface Foo {
Bar getBar();
void setBar();
}
The question to ponder is whether this change should cause a major or minor version-
number increase. It depends on whether the interface is intended to be implemented
or used by the consumer. In the former case, the addition of the method is a binary-
incompatible change to the interface and should cause the major version number to
increase to 2.0.0. In the latter case, increasing the minor version number to 1.1.0 is
sufficient because method addition is a backward-compatible update to the interface.
Figure 9.2 shows the situation.
If you're in control of all the bundles, you can define a policy to ensure that
method addition always causes a change in the major version number, which allows all
consumers of a package to use a [1.0,2.0) version range. In reality, you're unlikely to
be in control of all the bundles. Furthermore, such a drastic policy would limit the
reusability of your bundles, because consumers only using the interfaces would have
no way to express that they're fine with an added method.
Foo
Foo
Foo user
Foo user
+getBar()
+getBar()
+setBar()
Foo implementor
Foo implementor
Add new method to Foo
Figure 9.2 Impact on versioning between using and implementing the interface
Search WWH ::




Custom Search