Lambdas and serialization

[Rémi Forax]

Hi tom,

Le 19/10/2010 21:50, tom.hawtin at oracle.com a écrit :
> On 19/10/2010 16:44, Rémi Forax wrote:
>
>> Lambda are not serializable, like java.lang.reflect.Method
>> because it will create tons of security holes.

sorry, I mean method handle are not serializable.
Lambda can be serializable if the spec change :)

>
> Having lambdas serialisable by default would rather put them out of 
> bounds for code that deals with other less trusted code. However, as 
> anonymous inner classes, it is not a security issue that they can be 
> serialisable if the creator explicitly wants them to be.

Yes, perhaps the lambda spec should be modified to add a way for the 
user to request serialization.
In that case, the compiler need to provide a dedicated support for that 
by storing more information
that just a method handle.

>
>> BTW, inner classes have some trouble with serialUID.
>
> Depends on the purpose. If you go right back serialisation was part of 
> making both data and code mobile. In a way that may be thought of as 
> object oriented (probably a dangerous thought). If the data and code 
> is in step, then the default serialVersionUID calculation is ideal. 
> Unfortunately provided mechnanisms for keeping data and code in step a 
> tad "lightweight" and this isn't really how serialisation appears to 
> be used these days.

There is another problem if you want migrate the code, where to stop, 
you can easily construct example
where the whole application code need to be transferred.

>
> Perhaps it would be useful to extend the SAM syntax to enums (SAMEs?), 
> for stateless lambdas. Or perhaps Java has deeper issues with objects 
> capturing state (compare against Simula).

Yes, something like enum, a lambda can be encoded as a class and a 
method name/method descriptor +
some bound arguments.
I don't see any issue with bound object if there are serializable.
Method handle bind objects using theirs values (like inner-classes) with 
a semantics which is at least
as strong as reading the values in final fields.

>
> Tom Hawtin

Rémi