There seem to be a problem in src bridge, as an empty MethodElement array is
obtained from ClassElement, but the method(s) should be there.
 See
org.netbeans.modules.j2ee.common.ui.nodes.ComponentMethodModel.updateKeys(). The
class element there is correctly updated to new package, but it does not return
any methods.
 When I tried (in that method) to resolve the class through jmi and obtain list
of methods through jmi, then the list of methods is returned correctly. First I
wanted to rewrite the updatekeys method to jmi, but then I realized that this
would require rewrite of almost all nodes which may be quite risky these times.

 I don't know why the information isn't synchronized, so reassigning to java
team for deeper evaluation. 
 If there's anything we can do on our side, please let me know.

Dan, please look at it.

There is a problem that whenever a package is renamed, all resources (and java
classes residing in them) are deleted and created again - the old jmi elements
become invalid. Src hierarchy elements keep the old, invalid jmi elements (there
is no refresh mechanism for this case, it is only implemented  by SourceElement)
which causes that no methods are returned when a class element is queried.

This problem can be solved in the javacore module (do not recreate resource
elements when a package is renamed) or in src bridge (implement some refresh
mechanism also for ClassElements, MethodsElements, etc.), however, both these
solutions are risky - to implement the refresh mechanism in src bridge will
require a lot of changes.

Another solution is to not pass the interfaces parameter to ComponentMethodModel
constructor, use getInterfaces method whenever the interfaces are needed and
implement getInterfaces method in subtypes as follows:

protected Collection getInterfaces() {
  return controller.getLocalInterfaces();
}

It works since the interfaces are obtained from SourceElements that are able to
refresh their jmi resource element. On the other hand, this fix is local only,
there can be possibly another situations when renaming of a package would cause
problems...

Created attachment 21267 [details]
diff files

Thanks for the patch, I'll fix it that way. It's easy and safe solution for 4.1
- if there are more problems found, we may decide to go for a different fix, but
for now I think it's ok.

I have found one more problem in ComponentMethodModel (with listeners that must
be registered again when class elements became invalid after package rename),
replace related diff file in the previous attachement with the diff file that
follows, please.

Created attachment 21270 [details]
ComponentMethodModel.diff

Fixed in trunk. Some more changes were needed.

v.