On Aug 12, 2008, at 1:24 AM, Lukas Stadler wrote: > I was looking at your method handle changeset and I was wondering > if in the long run method handles will be serializable? > Thinking about (serializable) continuations it would be very > convenient if method handles would behave like java.lang.Class > (which are serializable).
Interesting point. Here's the catch: A method handle is a capability to call the method, even if it is not public. If it were simply serializable, it would be easy to forge capabilities to private members. A reflective method with the accessible bit set is also such a capability, so there's a similar argument there. > Currently if you want to store a continuation you have to work > around the fact that reflect.Method isn't serializable... Right. As you know, this is one of the challenges working with continuations: You get the interior state of a computation, some of which may be private to a class, and you don't want to open up a security hole by allowing untrusted parties to inspect the contents of that state via a serialization, or (much worse) to forge similar states by editing serialized continuations. What we need is a way for trusted parties to serialize the method (and other continuation parts) with the understanding that the serializations will be kept private, or at least sanitized when exiting trust boundaries, and verified when entering them. For method handles, this means we need at least a partial reflection API for them. Currently, for direct method handles only, you can get their type (which is public anyway) and the method name as a string. I'm not concentrating on such an API, since it is not necessary to making invokedynamic a success, but it will have to be thrashed out at some point. Thanks for thinking about this! -- John _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
