hg: lambda/lambda/jdk: 3 new changesets

[Brian Goetz]

Also, there's room for a special case where there is exactly one 
captured parameter, and the implementation method handle is an instance 
method.  This means the sole parameter is the receiver, and we can used 
bindTo instead of insertArgs, which is a shorter capture path.

The "translate by method handle proxies" is largely a proof-of-concept 
to demonstrate that we can change implementation strategies on a 
run-to-run basis while holding the bytecode stable.  As a translation 
strategy, it is not great.  It will be slower (uses dynamic proxy in the 
implementation), doesn't yet have a path to supporting serialization, 
and the MHProxy implementation has bugs (filed CR 7163223 to track these.)

The good news is that, modulo the above bug report, the approach works. 
  We have two metafactory implementations, choosable by setting a system 
property, and I have tests that generate thousands of combinations of 
argument and return types, generate source code, compile it, assert that 
the compiler yields the right diagnostics, for the classes that pass the 
compiler loads them, runs them, and asserts that we get the right 
answer.  And both metafactories pass these tests, modulo bug 7163223.

(To run these tests: go to the lambda repo, cd to jdk/combo-tests, drop 
the appropriate version of the testng JAR into the lib/ subdirectory, 
and do "ant test."  We're in the process of integrating testng support 
into jtreg, at which point these tests will move to the main test area.)

What this experiment with MH proxies does point us towards is 
implementing the second realistic metafactory implementation, the one 
that generates a single wrapper class per SAM type, whose constructor 
takes a MethodHandle, and whose SAM methods invoke that handle.  That's 
coming soon, but first I am working on some more tests regarding bridge 
methods.

(Lots more details in the document I just posted to this list.)

On 4/22/2012 6:23 AM, Rémi Forax wrote:
> On 04/21/2012 11:58 PM, brian.goetz at oracle.com wrote:
>> Changeset: 59aa44ba1555
>> Author:    briangoetz
>> Date:      2012-04-21 17:56 -0400
>> URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/59aa44ba1555
>>
>> Minor improvements in combo-test framework and lambda tests
>>
>> ! combo-tests/build.xml
>> ! combo-tests/tests/tools/javac/combo/JavacTemplateTestBase.java
>> ! combo-tests/tests/tools/javac/combo/Template.java
>> ! combo-tests/tests/tools/javac/lambda/LambdaConversionTest.java
>>
>> Changeset: b166fa7adaea
>> Author:    briangoetz
>> Date:      2012-04-21 17:56 -0400
>> URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b166fa7adaea
>>
>> Minor improvements in combo-test framework and lambda tests
>>
>> ! test-ng/build.xml
>> ! test-ng/tests/org/openjdk/tests/java/util/functions/MappersTest.java
>>
>> Changeset: d0e63cae6a1c
>> Author:    briangoetz
>> Date:      2012-04-21 17:57 -0400
>> URL:       http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d0e63cae6a1c
>>
>> Allow metafactory option to be choosable at runtime via lambda.metafactory system property; first cut at second translation strategy (method handle proxies)
>>
>> ! .hgignore
>> ! src/share/classes/java/lang/invoke/InnerClassGenerator.java
>> ! src/share/classes/java/lang/invoke/LambdaMetafactory.java
>> + src/share/classes/java/lang/invoke/MagicLambdaImpl.java
>> ! src/share/classes/java/lang/invoke/MethodHandleProxies.java
>> + src/share/classes/java/lang/invoke/MethodHandleProxyLambdaMetafactory.java
>>
>>
>
> Hi Brian,
> I think you don't need the MhMetafactoryCallSite because
> the arguments of MethodHandle.asInterfaceInstance are known during the
> bootstrap.
> The idea is that instead of the method factory,() you can bind the
> method bindTo itself.
> I will try to come with a code, it will be more clear :)
>
> Rémi
>
>
>