OSGi bundles won't start - Unable to resolve sun.reflect.generics.reflectiveObjects

Question

After seemingly irrelevant changes in the code of my AEM project, my bundle fails to resolve. Upon inspecting the logs, I can see the following errors appearing.

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)]]

The project compiles just fine locally and the problem only occurs after the bundle's installation when the container attempts to resolve it.

I haven't added any explicit dependencies in any of my changes. The Project Object Models are the same as before. The name implies this is a core Java package so I'd expect it to be exposed by the System bundle.

I'm running JDK 7, which is supported by AEM so do not expect it to be a matter of JVM compatibility. At least when AEM internals are concerned.

Answer 1

The package sun.reflect.generics.reflectiveObjects is part of the JDK but it's not part of the Java API, as explained in Oracle's documentation for Java 7 compatibility

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.

This explains why the package is not exported by the System bundle in Apache Felix, underlying AEM. A very reasonable decision indeed. The code compiled locally because the package was in my classpath but it failed at runtime, which is all fine and to be expected.

My code should not have been using this package in the first place. There are two possible ways of introducing a dependency on these packages.

1. Use a library that uses these classes for some reason and introduce a transitive dependency. This isn't what happened.

2. Import one of these classes - a very silly thing to do. If someone uses a class, they should know what it is.

In my case, I explicitly imported a class from this package without noticing it.

It turns out that the sun.reflect.generics.reflectiveObjects package contains a NotImplementedException class, the name of which coincides with the often-used NotImplementedException from apache.commons.lang3.

I accidentally imported it when it was auto-completed in my IDE and failed to notice this for a long time. It took me a git bisect to isolate the change.

After this happened, I excluded the sun.* packages from autocomplete.