问题描述
该软件包sun.reflect.generics.reflectiveObjects是JDK的一部分，但不是Java
API的一部分，如Oracle有关Java 7兼容性的文档中所述
这些
sun.*软件包 。sun.*不能保证直接调用程序包的Java程序可以在所有与Java兼容的平台上运行。实际上，即使在同一平台上的将来版本中，也无法保证此类程序可以正常工作。
这就解释了为什么软件包不是由基础AEM的Apache Felix中的 System 捆绑软件导出的。确实是一个非常合理的决定。该代码在本地编译，因为该程序包位于我的类路径中，但在运行时失败，这一切都很好并且可以预期。
我的代码最初不应该使用此程序包。有两种方法可以引入对这些程序包的依赖关系。
-
使用出于某种原因而使用这些类的库，并引入可传递的依赖关系。这不是事实。
-
导入这些类之一-这是一件非常愚蠢的事情。如果有人使用课程，他们应该知道它是什么。
就我而言，我从该包中显式导入了一个类，而没有注意到它。
事实证明，该sun.reflect.generics.reflectiveObjects程序包包含一个NotImplementedException类，该类的名称与经常使用的NotImplementedExceptionfrom相同apache.commons.lang3。
当它在我的IDE中自动完成时，我不小心将其导入，并且很长一段时间都没有注意到它。我花了一个时间git bisect来隔离更改。
发生这种情况后，我sun.*从自动完成中排除了软件包。
解决方法
在我的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内部时。