为什么 OSGi 声明式服务 (DS) 注释不是从超类继承的？答案

【问题标题】：Why aren't OSGi Declarative Services (DS) annotations inherited from super classes?为什么 OSGi 声明式服务 (DS) 注释不是从超类继承的？
【发布时间】：2016-10-07 12:02:16
【问题描述】：

OSGi 声明式服务 (DS) 规范定义了注释，这些注释可以被 Bnd 等工具处理到在运行时使用的组件描述 xml 中。 R6 规范中的 112.8.1 说：

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.

为什么它们被指定为不允许继承？

【问题讨论】：

标签： java inheritance osgi declarative

【解决方案1】：

Apache Felix 项目提供的 DS 注释曾经支持 DS 可扩展性。基于此实现，我们尝试将其标准化为特定于官方 OSGi DS 注释的工作的一部分。

但问题是，我们在跨包边界的两个实现类之间遇到了令人讨厌的耦合问题，并且我们无法使用 Import-Package 或 Require-Capability 标头正确表达这种依赖关系。

突然想到的一些问题：

通常您希望将bind 和unbind 方法设为私有。 DS 可以调用基类上的私有bind 或unbind 方法吗？（从技术上讲，这可以很好地完成，但在概念上可以吗？）
如果我们有私有方法但实现者决定更改私有方法的名称怎么办？毕竟它们是私有的，而不是 API 表面的一部分。扩展程序将失败，因为 bind/unbind 方法列在扩展类提供的描述符中，并且它们仍然命名旧方法名称。
如果我们不支持私有方法名称，我们将要求这些 bind/unbind 方法受到保护或公开。因此我们强制实现细节方法成为 API 的一部分。恕我直言，不是很好。
注意：包私有方法不起作用，因为两个不同的包不应共享具有不同内容的同一个包。

我们当时争论说，在单个捆绑包中拥有这样的继承是可以的，但得出的结论是，这种限制、围绕它的解释等不值得付出努力。因此，我们再次从规范路线图中删除了该功能。

【讨论】：

“因此，我们强制实现细节方法成为 API 的一部分。恕我直言，这不是很好。”。在我们的组件模型（90% 像 DS）中，只有 bind 和 setter 方法只能是公共的。由于组件类通常不在导出的包中，因此这些函数不会成为任何 API 的一部分。在我看来，调用 method.setAccessible(true) 比强迫人们使用公共绑定方法要糟糕得多。
但是组件类可以作为服务对象使用，所以这些公共的绑定/解除绑定方法在共享服务对象上都有。