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

Bug 349487

Summary:	[1.7] IMethodBinding#getJavaElement() returns inexistent element for @PolymorphicSignature methods
Product:	[Eclipse Project] JDT	Reporter:	Markus Keller <markus.kell.r>
Component:	Core	Assignee:	Olivier Thomann <Olivier_Thomann>
Status:	VERIFIED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	amj87.iitr, Olivier_Thomann, satyam.kandula
Version:	3.7
Target Milestone:	3.7.1
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description Markus Keller

2011-06-15 14:39:02 EDT

BETA_JAVA7

IMethodBinding#getJavaElement() returns inexistent elements for @PolymorphicSignature methods. Can be seen in the ASTView with the "Usage examples" from the Javadoc of java.lang.invoke.MethodHandle.

The Object#getClass() method from 1.5 is a similar case. There, the return type of invocations doesn't match the return type of the method declaration. IMethodBinding#getJavaElement() there returns IMethods that are equal to each other and to the declaration, although they have different return types.

With PolymorphicSignature methods, also the argument types can vary. I guess it would be best here to always return an IMethod that matches the signature of the declaration.

Comment 1 Olivier Thomann

2011-06-15 14:45:11 EDT

(In reply to comment #0)
> With PolymorphicSignature methods, also the argument types can vary. I guess it
> would be best here to always return an IMethod that matches the signature of
> the declaration.
So two invokeExact(..) would return the same IMethod ?

Comment 2 Markus Keller

2011-06-15 14:54:58 EDT

> So two invokeExact(..) would return the same IMethod ?

Yes. When bug 349488 is fixed, I'd expect the same as getMethodDeclaration().getJavaElement().

Comment 3 Olivier Thomann

2011-06-15 16:01:03 EDT

What do you expect for polymorphic methods for the parameter types ? The actual parameter types or Object[] ?
Same question for the return type ?

Comment 4 Markus Keller

2011-06-16 05:32:37 EDT

I don't think we should have multiple IMethods in the model that exist and are equal but don't have the same parameter types.

The Java element model is mainly a declaration model, with only 2 exceptions so far:
- there can be multiple versions of Object#getClass() that differ in the return types
- resolved ITypes and IMethods can have different keys (depending on the actual type arguments), but their signatures still match the declaration

For the declaration and for references to the 2 methods, I'd expect
- return type Object
- parameter type Object[]
- varargs flag


For references to the methods, IMethodBinding#getJavaElement() and codeSelect(..) should return IMethods whose isResolved() is true and whose getKey() returns the binding key of the method binding of the corresponding MethodInvocation node.

Comment 5 Satyam Kandula

2011-06-21 01:25:27 EDT

I believe bug 349486 fails for the same reason

Comment 6 Olivier Thomann

2011-06-21 16:29:26 EDT

Released in BETA_JAVA7 branch.

Comment 7 Ayushman Jain

2011-07-01 09:28:16 EDT

Verified using Eclipse Java 7 support(BETA) version v_B66