Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 284131

Summary: failure to decode binary parameterized anonymous class
Product: [Eclipse Project] JDT Reporter: Stephan Herrmann <stephan.herrmann>
Component: CoreAssignee: Olivier Thomann <Olivier_Thomann>
Status: CLOSED DUPLICATE QA Contact:
Severity: normal    
Priority: P3 CC: Olivier_Thomann, stephan.herrmann
Version: 3.5   
Target Milestone: ---   
Hardware: Other   
OS: All   
Whiteboard:
Attachments:
Description Flags
Jar file used for reproducing this bug
none
proposed patch - draft
none
updated (reduced) patch none

Description Stephan Herrmann CLA 2009-07-21 10:12:27 EDT 
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
Comment 1 Stephan Herrmann CLA 2009-07-21 10:20:39 EDT 
Created attachment 142137 [details]
Jar file used for reproducing this bug
Comment 2 Stephan Herrmann CLA 2009-07-21 10:28:33 EDT 
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?
Comment 3 Stephan Herrmann CLA 2009-07-21 10:50:53 EDT 
The createMethods part is not quite right, yet - still working on it.
Comment 4 Stephan Herrmann CLA 2009-07-21 11:33:01 EDT 
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?
Comment 5 Stephan Herrmann CLA 2009-07-21 13:22:49 EDT 
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??
Comment 6 Stephan Herrmann CLA 2009-09-14 19:45:44 EDT 
May want to compare this to bug 288920.
Comment 7 Olivier Thomann CLA 2009-09-14 21:15:33 EDT 
I think this has been fixed as part of the fix for bug 288920.
Comment 8 Stephan Herrmann CLA 2009-09-15 08:22:13 EDT 
(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.
Comment 9 Stephan Herrmann CLA 2009-09-15 10:56:46 EDT 
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 ***