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

Question

在我的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软件包公开。

我正在运行AEM支持的JDK 7，所以不要指望它与JVM兼容性有关。至少在涉及AEM内部时。

Answer 1

该软件包sun.reflect.generics.reflectiveObjects是JDK的一部分，但不是Java
API的一部分，如Oracle有关Java 7兼容性的文档中所述

这些sun.*软件包 不是受支持的public接口的一部分
。sun.*不能保证直接调用程序包的Java程序可以在所有与Java兼容的平台上运行。实际上，即使在同一平台上的将来版本中，也无法保证此类程序可以正常工作。

这就解释了为什么软件包不是由基础AEM的Apache Felix中的 System
捆绑软件导出的。确实是一个非常合理的决定。该代码在本地编译，因为该程序包位于我的类路径中，但在运行时失败，这一切都很好并且可以预期。

我的代码最初不应该使用此程序包。有两种方法可以引入对这些程序包的依赖关系。

1. 使用出于某种原因而使用这些类的库，并引入可传递的依赖关系。这不是事实。

2. 导入这些类之一-这是一件非常愚蠢的事情。如果有人使用课程，他们应该知道它是什么。

就我而言，我从该包中显式导入了一个类，而没有注意到它。

事实证明，该sun.reflect.generics.reflectiveObjects程序包包含一个NotImplementedException类，该类的名称与经常使用的NotImplementedExceptionfrom相同apache.commons.lang3。

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

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