JDK-6991980 : polymorphic signature calls don't share the same CP entries
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 7
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: unknown
  • Submitted: 2010-10-14
  • Updated: 2011-03-08
  • Resolved: 2011-03-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7 b116Fixed
Related Reports
Relates :  
Description
The following example:

import java.dyn.*;

class Test {

void test(MethodHandle mh) throws Throwable {
   String s = mh.<String>invokeExact("daddy",'d','n');   //this works but gets warning to use new syntax
   s = (String)mh.invokeExact("bunny",'n','d');  //this throws exception
}
}

produces a classfile that uses two separate constant pool method entries for encoding the signatures of the PS methods.

Comments
SUGGESTED FIX A webrev of this fix is available at the following URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/493ecc8111ba
18-10-2010

SUGGESTED FIX The problem is trivial, and is related to the fact that the code in Infer.instantiatePolymorphicSignatureInstance uses env.outer that doesn't always do the right thing. The solution is to use a more conservative approach using TreePaths.
14-10-2010

EVALUATION The problem is caused by the fact that javac is not able to reconstruct the correct signature when using the cast notation - one method is seen as returning String, while the other (with cast) is seen as returning Object, hence the separate CP entries.
14-10-2010