RFR (M) 8001110: method handles should have a collectArguments transform, generalizing asCollector

Christian Thalinger christian.thalinger at oracle.com
Fri Oct 4 11:17:38 PDT 2013


src/share/classes/java/lang/invoke/MethodHandles.java:

You have renamed "coll" to "filter" but the documentation still references "coll" in multiple places, e.g.:

+     * If the filter method handle {@code coll} consumes one argument and produces
+     * a non-void result, then {@code collectArguments(mh, N, coll)}
+     * is equivalent to {@code filterArguments(mh, N, coll)}.

Otherwise this looks good.

On Sep 12, 2013, at 7:55 PM, John Rose <john.r.rose at oracle.com> wrote:

> Please review this change for a change to the JSR 292 implementation:
> 
> http://cr.openjdk.java.net/~jrose/8001110/webrev.00/
> 
> Summary: promote an existing private method; make unit tests on all argument positions to arity 10 with mixed types
> 
> The change is to javadoc and unit tests, documenting and testing some corner cases of JSR 292 APIs.
> 
> Bug Description:  Currently, a method handle can be transformed so that multiple arguments are collected and passed to the original method handle. However, the two routes to doing this are both limited to special purposes. 
> 
> (They are asCollector, which collects only trailing arguments, and only into an array; and foldArguments, which collects only leading arguments into filter function, and passes both the filtered result *and* the original arguments to the original.)
> 
> MethodHandles.collectArguments(mh, pos, collector) should produce a method handle which acts like lambda(a*, b*, c*) { x = collector(b*); return mh(a*, x, c*) }, where the span of arguments b* is located by pos and the arity of the collector.
> 
> There is internal machinery in any JSR 292 implementation to do this. It should be made available to users.
> 
> This is a missing part of the JSR 292 spec.
> 
> Thanks,
> — John
> 
> P.S. Since this is a change which oriented toward JSR 292 functionality, the review request is to mlvm-dev and core-libs-dev.
> Changes which are oriented toward performance will go to mlvm-dev and hotspot-compiler-dev.
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev



More information about the mlvm-dev mailing list