method handle cracking API

[Christian Thalinger]

On Apr 25, 2013, at 8:58 AM, "MacGregor, Duncan (GE Energy Management)" <duncan.macgregor at ge.com> wrote:

> I would have thought one of the most common uses of breaking down a method
> handle like this would be to immediately turn it into a java.lang.reflect
> object and maybe examine annotations or exception information. So although
> I don't think it should extend Member I do think it should have a standard
> way to return a Member, sort of the opposite of Lookup.unreflect().

John and I referred to this method yesterday as:  Lookup.ununreflect()

;-)

-- Chris

> 
> As for transformed method handles a cracking interface may not need to
> return an representation of the original structure, it might be enough to
> return the parts that remain (both method handles and bound objects) as I
> would guess that would be enough for debugging purposes and resource leak
> hunting.
> 
> Regards, Duncan.
> 
> On 24/04/2013 08:02, "John Rose" <john.r.rose at oracle.com> wrote:
> 
>> Those of you who have been following 292 details may have noticed the
>> type java.lang.invoke.MethodHandleInfo show up in support of Project
>> Lambda.
>> 
>> The 292 EG has been thinking about the problem of method handle
>> reflection, since JDK 7, in background mode.  We are sure we want
>> something that can "crack" direct method handles, and not ready to
>> venture anything more elaborate.
>> 
>> (Arbitrarily transformed method handles probably can never have an
>> implementation-independent cracked form, so there are real problems
>> specifying a cracking function that is defined for every method handle.
>> For example, recording the series of transforms that gave rise to every
>> MH rules out many interesting implementations, and recovering a "likely"
>> series of transforms for a MH seems perilously close to the
>> function-equivalence problem, which we know is undecidable.)
>> 
>> I am working on polishing this restricted cracking API for direct method
>> handles.  Here is a webrev of it, starting at MethodHandleInfo:
>> 
>> http://cr.openjdk.java.net/~jrose/8008688/javadoc.00/java/lang/invoke/Meth
>> odHandleInfo.html
>> 
>> Comments would be welcome.
>> 
>> Thanks,
>> ‹ John
>> 
>> P.S. No testing yet; it is doc-ware at the moment.  I just posted a
>> checkpoint of the source patches here:
>> 
>> http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/meth-info-8008688.patch
>> 
>> P.P.S.  Here are my fix-me comments at this point:
>> 
>> // Should this extend java.lang.reflect.Member?  (default: no)
>> // Should we include getModifiers?  (default: no)
>> // Should the direct parts be separated into a sub-interface (to allow
>> for future extensions)?
>> //    If we don't have a subinterface, later on we might need an isDirect
>> method.
>> //    If we do have a subinterface, then MethodHandleInfo becomes an
>> empty type (like java.lang.reflect.Type).
>> // Define SecurityManager checks. (TO DO)
>> 
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> 
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev