The HotSpot JVMCI implementation of ResolvedJava[Method|Field].getAnnotation() and other related methods use standard Java reflection (e.g. [3]). When converting a JVMCI object to a Method|Field|Constructor object, a NoClassDefFoundError can occur if a type in the element's signature cannot be loaded (e.g., due to an incomplete class or module path). Currently, JVMCI swallows this error[1] and thus can return an incorrect value for these JVMCI API calls. This can lead to very confusing errors or behavior.

For example, a method, M1, in a Truffle language implementation can be annotated by @TruffleBoundary to denote that Truffle partial evaluation (PE) should stop at a call to M1. PE calls ResolvedJavaMethod.getAnnotation(TruffleBoundary.class) to check this condition. However, if there is some *other* method, M2, in the same class as M1 that has an unloadable type in its signature the call to getAnnotation will return null. This is because Java reflection builds all j.l.r.Method objects for a class at once. A NoClassDefFoundError will be thrown while trying to build the j.l.r.Method for M2.

The solution[2] is to not swallow NoClassDefFoundErrors thrown when converting a JVMCI object for a field or method to a j.l.r object.

[1] http://hg.openjdk.java.net/jdk/jdk/file/cb8cab787ba2/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java#l600
[2] https://github.com/graalvm/graal-jvmci-8/commit/8cb584f15c9ed8fc509615fc439c3477a931777a
[3] http://hg.openjdk.java.net/jdk/jdk/file/cb8cab787ba2/src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaMethodImpl.java#l529