Re: Re: Method[Hande|Type] name clash between java.lang.invoke and org.objectweb.asm

22/04/2011 11:11, Tronje Krop wrote:
> Hi Remi, hi all,
>
> thanks for bringing it up again, because I noticed something before.
>
> May I ask, why you have introduced a MethodType|Handle in ASM in the first
> place?
>
> IMHO the MethodType|Handle in ASM it is a breach of the well chosen design
> rules, that should be urgently discussed before fixing the API of ASM 4.
>
> (1) MethodType
>
> The MethodType is only a wrapper for a method description string with some
> convenience methods. It only transports the once verified information of
> being a method type, that can be derived from the string itself.
>
> In ASM such information, in general, is provided as describing string, and
> only its parameter position or its format may give you an additional hint
> about its context.
>
> I do not suggest that it is good programming style, but it is the common
> pattern of ASM that should not easily be dropped without questioning.

in visitLdcInsn we cannot deduce from a string alone if this string must 
be interpreted as a CONSTANT_String or a CONSTANT_Class value. This is 
why we used Type to represent .class constants, instead of String.

In the same way we cannot deduce from a string alone if its a 
CONSTANT_String or a CONSTANT_MethodType value. This is why we 
introduced the MethodType class.

The other solution that we considered was to introduce new visitLdcInsn 
methods, such as visitLdcClassInsn, visitLdcMethodTypeInsn, etc. But 
this solution does not solve the second problem (see below).

> (2) MethodHandle
>
> For MethodHandle it is a different story. I think this class may have a
> right of its own, although it is very common in ASM to leave the bundling
> of information to the visitor interfaces. E.g. a common bundle is the
> tuple of (access, name, desc, signature) that is used either for fields
> or methods. And there are many other places that may be simplified by
> bundling information into objects.

the second problem with CONSTANT_MethodType and CONSTANT_MethodHandle is 
that they can be used as optional arguments in a bootstrap method 
description (see the last argument of visitInvokeDynamicInsn). We 
considered that using MethodType and MethodHandle classes was a good 
solution to this problem. The other solution we considered was to define 
a new interface with methods very similar to the visitLdcInsn, 
visitLdcClassInsn, visitLdcMethodTypeInsn, etc:

BsmArgVisitor visitInvokeDynamicInsn(String name, String desc,
     int bsmTag, String bsmOwner, String bsmName, String bsmDesc);

with:

public interface BsmArgVisitor {
     void visitArg(Object o);
     void visitClassArg(String c);
     void visitMethodTypeArg(String mt);
     void visitMethodHandleArg(int tag, String owner, String name, 
String desc);
     void visitEnd();
}

and we considered that this design was too complex, with quite redundant 
methods with visitLdc...Insn.

Eric

-- 
You receive this message as a subscriber of the [email protected] mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
OW2 mailing lists service home page: http://www.ow2.org/wws