John,
I cleaned javadoc a little [1], so it is more readable in the browser now.
The test code looks ok, though the logic is over-complicated.
But the whole MethodHandlesTest is written in the same vein.
Best regards,
Vladimir Ivanov
diff --git a/src/share/classes/java/lang/invoke/MethodHandles.java
b/src/share/classes/java/lang/invoke/MethodHandles.java
--- a/src/share/classes/java/lang/invoke/MethodHandles.java
+++ b/src/share/classes/java/lang/invoke/MethodHandles.java
@@ -2013,6 +2013,7 @@
* <p>
* In all cases, {@code pos} must be greater than or equal to
zero, and
* {@code pos} must also be less than or equal to the target's arity.
+ * <p>
* <b>Example:</b>
* <p><blockquote><pre>
import static java.lang.invoke.MethodHandles.*;
@@ -2020,17 +2021,22 @@
...
MethodHandle deepToString = publicLookup()
.findStatic(Arrays.class, "deepToString", methodType(String.class,
Object[].class));
+
MethodHandle ts1 = deepToString.asCollector(String[].class, 1);
assertEquals("[strange]", (String) ts1.invokeExact("strange"));
+
MethodHandle ts2 = deepToString.asCollector(String[].class, 2);
assertEquals("[up, down]", (String) ts2.invokeExact("up", "down"));
+
MethodHandle ts3 = deepToString.asCollector(String[].class, 3);
MethodHandle ts3_ts2 = collectArguments(ts3, 1, ts2);
assertEquals("[top, [up, down], strange]",
(String) ts3_ts2.invokeExact("top", "up", "down",
"strange"));
+
MethodHandle ts3_ts2_ts1 = collectArguments(ts3_ts2, 3, ts1);
assertEquals("[top, [up, down], [strange]]",
(String) ts3_ts2_ts1.invokeExact("top", "up", "down",
"strange"));
+
MethodHandle ts3_ts2_ts3 = collectArguments(ts3_ts2, 1, ts3);
assertEquals("[top, [[up, down, strange], charm], bottom]",
(String) ts3_ts2_ts3.invokeExact("top", "up", "down",
"strange", "charm", "bottom"));
On 9/13/13 6:55 AM, John Rose 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@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
