On Sep 10, 2008, at 5:22 PM, Jochen Theodorou wrote:
> hmm... if I have a MethodHandle created by unreflect, then this handle
> does never call another method, does it?
It will dispatch exactly the way the reflective method does:
- no dispatch for static methods
- virtual dispatch for class methods
- interface dispatch for interface methods
So a direct method handle can access a range of methods, according to
JVM dispatch rules.
The unreflectSpecial method call creates a non-dispatching method
handle (if the caller has the rights to do so, which are limited).
> Object, int, long, double, float... so for 1 argument being one of
> these
> and one return value being one of these types I need 25 adapter
> classes.
> For 2 arguments it is 125. And with three arguments I break 256
> easily.
Yes, that 125 is exactly why I want to do flyby adapters and arglist
reification. But 125 (actually, the smaller number of actually used
signature types) is still smaller, by orders of magnitude, than the
number of all 2-argument methods in a system.
> if all is Object based it sure is a small number, but as soon as other
> classes or primitives are added the number explodes easily
The exponent base is 5, no larger, since subword types (Z,B,C,S) can
all be represented completely as ints. This fact will simplify the
API for reified argument lists.
> which reminds me of another question... if mh for example points to
> foo(String), can I invoke that with an Object (runtime type is of
> course
> a String), without doing the cast?
Not without an adapter. The method handle to String foo(String)
(from MHs.unreflect(..."foo"...)) must have a MethodType of exactly
String(String). You can call this method handle directly under the
signature of String(String) but no other signature. If you want to
use it from a call site (say an invokedynamic) of signature Object
(Object), then you must adapt the original method handle to a new
pass-through method handle of signature Object(Object), using
MethodHandles.convertArguments. There are *no* implicit conversions
in the design; all argument and return value conversions must be
carried out by explicitly adapting method handles. The good news is
that the commonest, lowest-level adaptations (such as checkcasts) are
likely to be efficiently supported by the JVM. This particular use
case is supported by an assembly coded adapter in my prototype.
> but....
>
>> Class.forName ("java.lang.PackagePrivateClass", true,
>> Object.class.getClassLoader())
>>
>
> I don't get the security argument yet I guess.
Actually, that's my mistake. I had forgotten that there are few
security checks on this call. (The defenses against malware are
access checks in reflect.Method.invoke, etc.) From the javadoc for
Class.forName:
> * Note that this method does not check whether the requested
> class
> * is accessible to its caller.
-- John
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to jvm-languages@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~----------~----~----~----~------~----~------~--~---
