13

The OSGi Declarative Services (DS) specifications define annotations which can be processed by tools, like Bnd, into the component description xml which is used at runtime. 112.8.1 in the R6 spec says:

The Component Annotations are not inherited, they can only be used on a given class, annotations on its super class hierarchy or interfaces are not taken into account.

Why are they specified to not allow inheritance?

BJ Hargrave
  • 9,324
  • 1
  • 19
  • 27

1 Answers1

15

The DS annotations provided by the Apache Felix project once had support for DS extensibility. Based on this implementation we tried to standardize this as part of the work specificying the official OSGi DS annotations.

The problem, though, is that we get into nasty coupling issues here between two implementation classes across bundle boundaries and we cannot express this dependency properly using Import-Package or Require-Capability headers.

Some problems springing to mind:

  • Generally you want to make bind and unbind methods private. Would it be ok for DS to call the private bind or unbind method on the base class ? (Technically this can well be done, but would it be conceptually ok ?)
  • What if we have private methods but the implementor decides to change the name of the private methods ? After all they are private and not part of the API surface. The extender will fail as the bind/unbind methods are listed in the descriptors provided by and for the extension class and they still name the old method names.
  • If we don’t support private method names for that we would require these bind/unbind methods to be protected or public. And thus we force implementation-detail methods to become part of the API. Not very nice IMHO.
  • Note: package private methods don’t work as two different bundles should not share the same package with different contents.

We argued back then that it would be ok-ish to have such inheritance within a single bundle but came to the conclusion that this limitation, the explanations around it, etc. would not be worth the effort. So we dropped the feature again from the specification roadmap.

fmeschbe
  • 331
  • 3
  • 5
  • 1
    "And thus, we force implementation-detail methods to become part of the API. Not very nice IMHO.". In our component model (that is 90% like DS) only bind and setter methods can be only public. As component classes are usually not in exported packages, these functions will not be part of any API. In my opinion, calling method.setAccessible(true) is much worse than forcing people using public bind methods. – Balazs Zsoldos Jun 07 '16 at 15:37
  • But the component class can be used as a service object, so these public bind/unbind methods are there on the shared service object. – BJ Hargrave Jul 18 '16 at 20:01