Community
Participate
Working Groups
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.
(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 ?
> So two invokeExact(..) would return the same IMethod ? Yes. When bug 349488 is fixed, I'd expect the same as getMethodDeclaration().getJavaElement().
What do you expect for polymorphic methods for the parameter types ? The actual parameter types or Object[] ? Same question for the return type ?
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.
I believe bug 349486 fails for the same reason
Released in BETA_JAVA7 branch.
Verified using Eclipse Java 7 support(BETA) version v_B66
