Hi,
I'm updating my dyanalang-invoke module for the changes in the RI. Overall, all
looks good. I noticed some things have been fixed, i.e. unreflect/findVirtual
etc. now correctly create a MH with a MethodType that indicates the correct
receiver type (and not generic java.lang.Object) even if it's not on the boot
class path. There was also the bug of MethodHandles.catchException not working
for exception types not on boot class path - I'll check that soon.
However, collectArguments() still doesn't create the correct type of the array,
but just a Object[]. I.e. this program:
import java.dyn.MethodHandle;
import java.dyn.MethodHandles;
import java.dyn.MethodType;
public class TestCollectArguments
{
public static void main(String[] args) throws Throwable
{
MethodHandle xs = MethodHandles.publicLookup().findVirtual(
TestCollectArguments.class, "xs", MethodType.methodType(
String.class, String.class, String[].class));
// This works
System.out.println(xs.invokeVarargs(new TestCollectArguments(), "a",
new String[] { "b", "c" }));
MethodHandle collecting = MethodHandles.collectArguments(xs,
MethodType.methodType(String.class, Object.class, String.class,
String.class, String.class));
// This fails
System.out.println(collecting.invokeVarargs(new TestCollectArguments(),
"a", "b", "c"));
}
public String xs(String y, String... z) {
for (String zz : z) {
y += zz;
}
return y;
}
}
will print:
abc
Exception in thread "main" java.lang.ClassCastException: required class
[Ljava.lang.String; but encountered class [Ljava.lang.Object;
at sun.dyn.MethodHandleImpl.raiseException(MethodHandleImpl.java:1246)
at sun.dyn.FilterGeneric$F4.invoke_C2(FilterGeneric.java:629)
at sun.dyn.ToGeneric$A4.target(ToGeneric.java:746)
at sun.dyn.ToGeneric$A4.targetA4(ToGeneric.java:747)
at sun.dyn.ToGeneric$A4.invoke_L(ToGeneric.java:756)
at java.dyn.MethodHandle.invokeVarargs(MethodHandle.java:334)
at TestCollectArguments.main(TestCollectArguments.java:21)
Any plans to have this fixed soon? I can alternatively code a workaround using
filterArguments...
Attila.
On 2010.03.25., at 11:29, John Rose wrote:
> The JSR 292 EG has been working with me to refine and clarify the spec for
> invokedynamic. I have pushed updates to the RI to reflect this ongoing work.
> For the record, here is javadoc for the current state of the RI:
>
> http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm/
>
> The presentation and logic of the javadoc is not perfect. Please do send me
> your suggestions for improvement!
>
> Here are some holes in the implementation that I know about and will fix soon:
>
> - translation from signatures to method types sometimes fails on classes not
> on the boot class path
>
> - java.dyn.MethodHandle inherits from a type MethodHandleImpl that needs to
> go away
>
> - adapter method handles cannot be built for some signatures, including those
> for which primitives precede references
>
> - MH.invokeGeneric behaves the same as MH.invokeExact (oops: it is supposed
> to be more permissive)
>
> Best wishes,
> -- John
> _______________________________________________
> mlvm-dev mailing list
> [email protected]
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________
mlvm-dev mailing list
[email protected]
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
