This bug was originally marked as duplicate of bug 120577, that is already resolved. This bug is still valid, so this seems to be another bug, but it might be related.
Build: NetBeans IDE 7.1 (Build 201112071828)
VM: Java HotSpot(TM) 64-Bit Server VM, 22.0-b10, Java(TM) SE Runtime Environment, 1.7.0_02-b13
java.lang.NullPointerException: #120577: Cannot resolve ElementHandle[kind=CLASS; sigs=org.glassfish.jersey.server.Application$2 ]; file: /home/m_potociar/sandbox/java.net/jersey/core-server/src/main/java/org/glassfish/jersey/server/Application.java@8b1e7dd6:25db187
Created attachment 115917 [details]
*** Bug 209932 has been marked as a duplicate of this bug. ***
WARNING [org.netbeans.modules.j2ee.metadata.model.api.support.annotation.PersistentObjectManager]: typesChanged: type ElementHandle[kind=CLASS; sigs=org.glassfish.jersey.server.Application$3 ] has dissapeared
element handle cannot be resolved. See http://statistics.netbeans.org/exceptions/messageslog?id=561205
This bug already has 5 duplicates
Created attachment 121008 [details]
Created attachment 137867 [details]
The problem appears to be that a client gets an ElementHandle from the index, which refers to an anonymous (or local) class, and this handle cannot be resolved. This appear to be caused by the Repair, which strips method bodies when the class' header is broken, which prevents the anonymous (and local) classes from being generated. But the index already contains references to them and returns them when someone asks.
To reproduce with the attach project:
1. unpack, open in the IDE, open both pkg208611.Broken and pkg208611.I in the editor
2. go to I and observe there is no implemented-by badge, and the log shows:
INFO [org.netbeans.api.java.source.ElementHandle]: Cannot resolve: ElementHandle[kind=CLASS; sigs=pkg208611.Broken$1 ]
3. go to Broken, and fix its superclass, go back to I: now the implemented-by badge appears and leads to Broken. But I think it should be present even in step 2.