OSGi 捆绑包无法启动 - 无法解析 sun.reflect.generics.reflectiveObjects答案

【问题标题】：OSGi bundles won't start - Unable to resolve sun.reflect.generics.reflectiveObjectsOSGi 捆绑包无法启动 - 无法解析 sun.reflect.generics.reflectiveObjects
【发布时间】：2015-07-04 03:06:07
【问题描述】：

在我的 AEM 项目代码发生看似不相关的更改后，我的包无法解析。检查日志后，我可以看到出现以下错误。

22.04.2015 11:00:18.650 *ERROR* [qtp1266495948-35]
org.apache.felix.http.jetty %bundles.pluginTitle:
Cannot start (org.osgi.framework.BundleException:
Unresolved constraint in bundle my-bundle
...
[caused by: Unable to resolve 401.121: missing requirement [401.121]
osgi.wiring.package; (osgi.wiring.package=sun.reflect.generics.reflectiveObjects)]]

该项目在本地编译得很好，并且仅在安装包后容器尝试解决问题时才会出现问题。

我没有在我的任何更改中添加任何显式依赖项。项目对象模型与以前相同。顾名思义，这是一个核心 Java 包，所以我希望它会被 System bundle 公开。

我正在运行 AEM 支持的 JDK 7，因此不要指望它是 JVM 兼容性问题。至少在涉及 AEM 内部时。

【问题讨论】：

标签： java osgi aem apache-felix

【解决方案1】：

sun.reflect.generics.reflectiveObjects 包是 JDK 的一部分，但它不是 Java API 的一部分，如 Oracle's documentation for Java 7 compatibility 中所述

sun.* 包不属于受支持的公共接口。直接调用sun.* 包的Java 程序不能保证在所有Java 兼容平台上都能正常工作。事实上，即使在同一平台上的未来版本中，也不能保证这样的程序可以正常工作。

这解释了为什么包没有被 Apache Felix 中的 System 包导出，底层 AEM。确实是一个非常合理的决定。代码在本地编译，因为包在我的类路径中，但在运行时失败，这一切都很好，是意料之中的。

我的代码一开始就不应该使用这个包。有两种可能的方式来引入对这些包的依赖。

出于某种原因使用使用这些类的库并引入传递依赖项。这不是发生的事情。
导入其中一个类 - 这是一件非常愚蠢的事情。如果有人使用一个类，他们应该知道它是什么。

在我的例子中，我从这个包中显式导入了一个类而没有注意到它。

原来sun.reflect.generics.reflectiveObjects包中包含一个NotImplementedException类，其名称与apache.commons.lang3中常用的NotImplementedException一致。

当它在我的 IDE 中自动完成时，我不小心导入了它，并且很长时间没有注意到这一点。我花了git bisect 来隔离更改。

发生这种情况后，我从自动完成功能中排除了 sun.* 包。

【讨论】：