MethodHandles#catchException bug in jdk7u40 and jdk8ea ?

[Jochen Theodorou]

Hi again,

I have a Groovy-indy program looking like this
https://gist.github.com/abargnesi/6628656

This did work in 7u25 and does not work in 7u40 or the developer preview
of jdk8. What I found out is, if you remove an argument the
IllegalArgumentException is not thrown

What I have (using 7u40 debug information) is a SimpleMethodHandle
type: (Class,int,Class,Class,Class,Class,Class,Class,Class)Object
lambda: convert=Lambda(a0:L,a1:L,a2:I,a3:L,a4:L,a5:L,a6:L,a7:L,a8:L,a9:L)=>{
t10:L=MethodHandle(int)Object(a2:I);
arity: 10

On this I call
MethodHandles.catchException(handle, GroovyRuntimeException.class,
UNWRAP_EXCEPTION);
UNWRAP_EXCEPTION is the the result of a findStatic and looks basically
like this:
> public static Object unwrap(GroovyRuntimeException gre) throws Throwable {
> throw ScriptBytecodeAdapter.unwrap(gre);
> }
(I add it more for the signature, than for the content.)

After the the call to catchException the type of the handle is changed
to one containing for everything Object, instead of the original type:

SimpleMethodHandle
type: (Object,Object,Object,Object,Object,Object,Object,Object,Object)Object
lambda:
collect=Lambda(a0:L,a1:L,a2:L,a3:L,a4:L,a5:L,a6:L,a7:L,a8:L,a9:L)=>{
t10:L=ValueConversions.array(a1:L,a2:L,a3:L,a4:L,a5:L,a6:L,a7:L,a8:L,a9:L);
t11:L=MethodHandle(Object[])Object(t10:L);t11:L}
arity: 10

Later on I add a switchpoint guard, which expects the original type and
thus I get a runtime error about mismatched types. With a lower arity
the type change does not happen.

Now.. looking at the documentation of the method I then this here:

> * T target(A..., B...);
> * T handler(ExType, A...);
> * T adapter(A... a, B... b) {
> * try {
> * return target(a..., b...);
> * } catch (ExType ex) {
> * return handler(ex, a...);
> * }
> * }

implies to me, that the type of the returned handle (adapter) should be
equal to the type of the handle target. And that would mean this is a bug.

Am I right about this? If this is no bug, then the documentation
absolutely needs an update, plus I doubt such behaviour is good for
performance.

bye blackdrag

--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org