Community
Participate
Working Groups
This looks like a continuation of bug 266582: Create a jar file from this class: public class Test { class MyRunnable<T> { /** Doc of my uber run method. */ public void run(T arg) { } } void enclosingMethod(final int i) { new MyRunnable<Integer>() { /** The run implementation. */ public void run(Integer j) { System.out.println(j); } }.run(3); } } Import the jar in another project, browse to class Test and hover over the selector of run(Integer). The hover shows the doc of this method but does not know about the super implementation. The error is silent: a CorruptedSignature problem is raised which causes Abort but nothing logged. The problem is in BinaryTypeBinding, looks like some lines have never been successfully executed. I'll attach a patch in a minute. I'm note exactly sure which other scenarios might also be affected by this bug. I noticed that the menu action "Open Superimplementation" complains that the method is not an overriding method, which is wrong. But my current patch does not affect that behavior so there might be another bug lurking. Another trigger: open type hierarchy on MyRunnable<T>: without patch you see two independent subtypes of Object. Also note, that the following scenarios do work even without my patch: - open super implementation by clicking the override marker - various searches
Created attachment 142137 [details] Jar file used for reproducing this bug
Created attachment 142139 [details] proposed patch - draft This patch fixes two issues: 1. in findMethod index arithmetics were wrong: searching for parameters must start _after_ the selector (was: constantly 1). 2. calling findMethod before createMethods would throw NPE due to this.methods == null (was masked because findMethod prematurely aborted) I wasn't quite sure about createFields, but for consistency's sake I avoid the case were methods are created but fields are not. Are there any cases where creating methods would depend on superclass and/or superinterfaces being initialized?
The createMethods part is not quite right, yet - still working on it.
Created attachment 142146 [details] updated (reduced) patch OK, invoking createMethods was wrong: - we need the methods of this.enclosing, not this - I could not reproduce the NPE I once saw Sorry for the noise. The reduced patch still fixes the issue for - hover over run(Integer) - open type hierarchy for MyRunnable One thing still puzzles me: when the type hierarchy is left open accross a workbench shutdown/start cycle, the anonymous type is missing, but that's not due to a bug in BinaryTypeBinding, since we don't even reach this part of the code. Anyone know from the top of their head why this is not called? Some caching?
One more thing: When changing the signature of enclosingMethod to -- say -- void enclosingMethod(java.util.List<E> l) we indeed get an NPE, but not due to missing this.methods, but due to mismatching BinaryTypeBinding <-> UnresolvedReferenceBinding in getExactMethod (called from BTB.findMethod) -> method is not found. We could now simply make this little change in findMethod: - parameters[i - startIndex] = this.environment.getTypeFromSignature(methodDescriptor, index, end, false, this, missingTypeNames); + TypeBinding parameter = this.environment.getTypeFromSignature(methodDescriptor, index, end, false, this, missingTypeNames); + if (parameter instanceof UnresolvedReferenceBinding) parameter = ((UnresolvedReferenceBinding)parameter).resolve(this.environment, false); + parameters[i - startIndex] = parameter; but still we get NPE because the methodDescriptor produces a raw binding whereas the method has a parameterized one. Should we use a specialized getExactMethod which compares encoded signatures instead of parameter type bindings??
May want to compare this to bug 288920.
I think this has been fixed as part of the fix for bug 288920.
(In reply to comment #7) > I think this has been fixed as part of the fix for bug 288920. Indeed, most is fix by fix for bug 288920. Good job ;-) Only the issues with the type hierarchy persist, where I see various things like (A) Type MyRunnable<T> is shown twice: Object MyRunnable<T> MyRunnable<T> new MyRunnable<Integer> (B) The anonymous class is missing (although being the focus type): Object MyRunnable<T> Hitting F4 on run() _within_ the anonymous type brings the anonymous type back to the UI - including subsequent pressing of F4. (C) After adding a parameter <E> to Test I sometimes see Object MyRunnable<E> Also combinations of these states can be observed. I've also seen F4 and Ctrl-t producing different results. Yet, I wasn't able to identify what exact gesture would lead to what exact state. With my latest observations it seems that none of my patches actually solved any issue with the type hierarchy, but it just happened to work at times and didn't at other times.
Marking as duplicate of bug 288920 because the problems in BinaryTypeBinding.cachePartsFrom() et al have indeed been fixed. So let's get rid of my rambling on those matters. I will open a separate bug for issues related to the type hierarchy. *** This bug has been marked as a duplicate of bug 288920 ***
