Re: RFR (M) 8001110: method handles should have a collectArguments transform, generalizing asCollector
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.r...@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-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: RFR (M) 8001110: method handles should have a collectArguments transform, generalizing asCollector
Yikes; good catch. I used javac -Xdoclint to find a couple typos in @param
also. — John
On Oct 4, 2013, at 11:17 AM, Christian Thalinger
christian.thalin...@oracle.com wrote:
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)}.
Re: RFR (M) 8001110: method handles should have a collectArguments transform, generalizing asCollector
Actually it's OK: The name coll is defined a couple lines up by the A
collection adapter {@code collectArguments(mh, 0, coll)} ..., and the term
filter is persistently applied to it. So I think it is intelligible as
posted. — John
On Oct 4, 2013, at 11:34 AM, John Rose john.r.r...@oracle.com wrote:
Yikes; good catch. I used javac -Xdoclint to find a couple typos in @param
also. — John
On Oct 4, 2013, at 11:17 AM, Christian Thalinger
christian.thalin...@oracle.com wrote:
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)}.
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: RFR (M) 8001110: method handles should have a collectArguments transform, generalizing asCollector
On Oct 4, 2013, at 2:40 PM, John Rose john.r.r...@oracle.com wrote:
Actually it's OK: The name coll is defined a couple lines up by the A
collection adapter {@code collectArguments(mh, 0, coll)} ..., and the term
filter is persistently applied to it. So I think it is intelligible as
posted. — John
I'm fine with that.
On Oct 4, 2013, at 11:34 AM, John Rose john.r.r...@oracle.com wrote:
Yikes; good catch. I used javac -Xdoclint to find a couple typos in @param
also. — John
On Oct 4, 2013, at 11:17 AM, Christian Thalinger
christian.thalin...@oracle.com wrote:
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)}.
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing list
mlvm-...@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: RFR (M) 8001110: method handles should have a collectArguments transform, generalizing asCollector
On Sep 20, 2013, at 5:09 PM, John Rose john.r.r...@oracle.com wrote: On Sep 20, 2013, at 3:07 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: I cleaned javadoc a little [1], so it is more readable in the browser now. Thanks; I applied those edits. I fixed the problem of a missing p in a few other places too. The test code looks ok, though the logic is over-complicated. But the whole MethodHandlesTest is written in the same vein. Thanks. (Looks like it wasn't written by a real test engineer.) :-D I try to not touch MethodHandlesTest. We should think about splitting it into smaller test cases. — John ___ mlvm-dev mailing list mlvm-...@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: RFR (M) 8001110: method handles should have a collectArguments transform, generalizing asCollector
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
* bExample:/b
* pblockquotepre
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.
Re: RFR (M) 8001110: method handles should have a collectArguments transform, generalizing asCollector
On Sep 20, 2013, at 3:07 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: I cleaned javadoc a little [1], so it is more readable in the browser now. Thanks; I applied those edits. I fixed the problem of a missing p in a few other places too. The test code looks ok, though the logic is over-complicated. But the whole MethodHandlesTest is written in the same vein. Thanks. (Looks like it wasn't written by a real test engineer.) — John
RFR (M) 8001110: method handles should have a collectArguments transform, generalizing asCollector
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.
