Serialization

[Tom Hawtin]

Alex Blewitt wrote:

> I agree that not all lambdas should be serializable. Are we talking
> 'static' as defined by the compiler, or by the developer in the
> source? I'd argue that a good compiler should be able to promote (for
> want of a better description) 'instance' closures to 'static' closures
> automatically iff the appropriate conditions hold (no references to
> this variables etc.). In that case, one would be able to use #int(int
> a) { return a*42; } as a serializable lambda, regardless of whether it
> was defined (in the source) as a static, instance, or stack-based
> variable.

Even without considering serialisation, I don't think we should be 
faithfully copying inner class' semantics of always taking the outer 
this. For small operations it's an absolute waste. Further, in light of 
the 1.5 JMM special treatment of final fields, I think we can drop the 
outer this if the lambda only uses final fields from outer instances. 
Yay for final.

FWIW, RMI allows remote code loading from the opposite party, using 
support provided by the serialisation mechanism. It's the RMI party 
trick. The Java Tutorial example for RMI is a general purpose compute 
engine. I don't really have a problem from a compatability point of view 
with serialising lambdas if they are going to be deserialised with the 
*exact* same class files.

However, from a security point of view automatically serialisable 
lambdas scares the hell out of me. Even function types where untrusted 
code comes into contact with more trusted code, I don't see working. We 
have enough trouble with the weak-typing interpretation of Runnable.

"The general contract of the method run is that it may take any action 
whatsoever."

This is essentially the contract of function types as well.

Tom