在对 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 包，因此我希望它由系统包公开。
我正在运行 JDK 7，它受 AEM 支持，因此不要指望这是 JVM 兼容性问题。至少在涉及 AEM 内部结构时是这样。
套餐sun.reflect.generics.reflectiveObjects是 JDK 的一部分，但不是 Java API 的一部分，如中所述Oracle 关于 Java 7 兼容性的文档 http://www.oracle.com/technetwork/java/faq-sun-packages-142232.html
The sun.*包不属于受支持的公共接口的一部分。
Java程序直接调用sun.*不保证包可以在所有 Java 兼容平台上运行。事实上，即使在同一平台上的未来版本中，也不能保证这样的程序能够工作。
这解释了为什么包没有被导出System捆绑在 Apache Felix 中，底层 AEM。确实是一个非常合理的决定。代码在本地编译，因为该包位于我的类路径中，但在运行时失败，这一切都很好并且是预期的。
我的代码一开始就不应该使用这个包。有两种可能的方法来引入对这些包的依赖关系。
使用出于某种原因使用这些类的库并引入传递依赖项。这不是发生的事情。
导入其中一个类——这是一件非常愚蠢的事情。如果有人使用一个类，他们应该知道它是什么。
就我而言，我明确地从此包中导入了一个类，而没有注意到它。
事实证明，sun.reflect.generics.reflectiveObjects包装内含一个NotImplementedException类，其名称与常用的一致NotImplementedException from apache.commons.lang3.
当它在我的 IDE 中自动完成时，我不小心导入了它，并且很长一段时间没有注意到这一点。我花了一个git bisect隔离更改。
发生这件事后，我排除了sun.*自动完成的包。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
