OSGi 捆绑包无法启动 - 无法解析 sun.reflect.generics.reflectiveObjects
OSGi bundles won't start - Unable to resolve sun.reflect.generics.reflectiveObjects
在我的 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's documentation for Java 7 compatibility[=21= 中所述]
The sun.* packages are not part of the supported, public interface.
A Java program that directly calls into sun.* packages is not guaranteed to work on all Java-compatible platforms. In fact, such a program is not guaranteed to work even in future versions on the same platform.
这解释了为什么 AEM 底层 Apache Felix 中的 System 包不导出包。确实是一个非常合理的决定。代码在本地编译，因为包在我的 class 路径中，但它在运行时失败了，这一切都很好并且在意料之中。
我的代码一开始就不应该使用这个包。有两种可能的方式引入对这些包的依赖。
出于某种原因使用使用这些 classes 的库并引入传递依赖性。事实并非如此。
导入其中一个 classes - 一件非常愚蠢的事情。如果有人使用 class，他们应该知道它是什么。
在我的例子中，我明确地从这个包中导入了一个 class 而没有注意到它。
原来sun.reflect.generics.reflectiveObjects包里有一个NotImplementedExceptionclass，名字和apache.commons.lang3中常用的NotImplementedException不谋而合.
我的 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 包，所以我希望它会被系统包公开。
我是 运行 JDK 7，它受 AEM 支持，所以不要期望它是 JVM 兼容性问题。至少在涉及 AEM 内部时是这样。
软件包 sun.reflect.generics.reflectiveObjects 是 JDK 的一部分，但它不是 Java API 的一部分，如 Oracle's documentation for Java 7 compatibility[=21= 中所述]
The
sun.*packages are not part of the supported, public interface. A Java program that directly calls intosun.*packages is not guaranteed to work on all Java-compatible platforms. In fact, such a program is not guaranteed to work even in future versions on the same platform.
这解释了为什么 AEM 底层 Apache Felix 中的 System 包不导出包。确实是一个非常合理的决定。代码在本地编译，因为包在我的 class 路径中，但它在运行时失败了，这一切都很好并且在意料之中。
我的代码一开始就不应该使用这个包。有两种可能的方式引入对这些包的依赖。
出于某种原因使用使用这些 classes 的库并引入传递依赖性。事实并非如此。
导入其中一个 classes - 一件非常愚蠢的事情。如果有人使用 class，他们应该知道它是什么。
在我的例子中，我明确地从这个包中导入了一个 class 而没有注意到它。
原来sun.reflect.generics.reflectiveObjects包里有一个NotImplementedExceptionclass，名字和apache.commons.lang3中常用的NotImplementedException不谋而合.
我的 IDE 中自动完成时不小心导入了它，很长一段时间都没有注意到这一点。我花了 git bisect 来隔离更改。
发生这种情况后，我从自动完成中排除了 sun.* 个包。