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

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.


(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.

This design was chosen for good reasons 7 years ago. To reduce the code
size of ASM and increase the performance. May be the second aspect is not
that important today or may even not be true after all the changes to the
hot spot compiler and garbage collector. Using bundle objects may reduce
the call stack size significantly for long visitor chains allot while
object creation and destroying for short lived objects is today for nearly
nothing and may not happen that often. Thus bundling may even improve
performance of ASM today.

Thus my suggestion is to question the design pattern chosen 7 years ago,
and check for the today consequences to performance as well as code size
especially with respect to mobile devices.

If we don't want to go that far, we should at least consider to stick to
the design patterns of ASM for MethodHandle too, which would at least be
consistent.

Anyhow, I do not see any reason to change the name of MethodHandle unless
we have smoking gun of inconvenience for doing otherwise (@Remi can you
provide us with such an example).

CU Tronje


Rémi Forax wrote:
> I know that we have already discussed about that point
> but I think it's important to change the name of MethodHandle|MethodType 
> in ASM4 API.
> 
> Here is an example of code (not written by me but I've written the same 
> kind of code)
> sent to the DaVinci mailing list:
> 
> java.lang.invoke.MethodType bsmType = 
> java.lang.invoke.MethodType./methodType/(
Anyhow, I do not see any reason to change the name of MethodHandle unless
we have smoking gun of inconvenience for doing otherwise
>      ConstantCallSite.*class*, Lookup.*class*, String.*class*, 
> java.lang.invoke.MethodType.*class*);
> mv.visitInvokeDynamicInsn(...,
>      new MethodHandle(..., bsmType.toMethodDescriptorString()));
> ...
> 
> The first line uses the java.lang.invoke API and the second line uses 
> the ASM API.
> java.lang.invoke.MethodType is used to generated the method descriptor of
> the bootstrap method.
> 
> In my opinion, it will be far more readable to don't name the ASM classes
> representing a constant method type and a constant method handle
> with the same name as their runtime cousins.
> 
> Rémi
> 
> 
>

-- 
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