Lambdas and serialization

[Alessio Stalla]

On Tue, Oct 19, 2010 at 5:44 PM, Rémi Forax <forax at univ-mlv.fr> wrote:
> Le 19/10/2010 16:10, Maurizio Cimadamore a écrit :
>> On 19/10/10 14:41, Alessio Stalla wrote:
>>
>>> On Tue, Oct 19, 2010 at 3:30 PM, Paul Benedict<pbenedict at apache.org>   wrote:
>>>
>>>
>>>> Will the wrapper be serializable if the SAM interface is? That's a
>>>> good question, but I imagine it has to be because it is implementing
>>>> the interface.
>>>>
>>>> public interface MySamType extends Serializable {
>>>>    void doSomething(int x);
>>>> }
>>>>
>>>>
>>> Sorry, I was unclear with the expression "be serializable": what I
>>> really meant is not if it will merely implement java.io.Serializable,
>>> rather if it will actually be serialized by an ObjectOutputStream
>>> without any exception in all cases where a "regular" instance of the
>>> SAM would have been serialized without exceptions, and deserialized in
>>> the same conditions as well. That's imho a desirable feature to have,
>>> but it places a possibly non-trivial burden on the implementation.
>>>
>>>
>>>
>> Good point. The short answer to this question is: it depends on how
>> lambda expressions are translated by the compiler. If the compiler uses
>> anonymous inner classes to translate away lambda expression, then the
>> answer is yes. If lambda expressions are to be translated away by using
>> method handles, then I *guess* the answer is no, as it seems like
>> MethodHandle are not serializable (Remi or John might know more about
>> this though).
>>
>> Maurizio
>>
>
> Lambda are not serializable, like java.lang.reflect.Method
> because it will create tons of security holes.

Do you care to elaborate? Are you thinking about malicious code
serializing a Method, changing the serialized bytes in order to alter
some object used for security checks, deserializing the Method, and
calling it? This, I think, could be avoided by customizing the
serialization of Methods to do security checks before serializing, as
if the method had been called, so that no untrusted code will be able
to serialize a method if it has no privilege to call it in the first
place. Maybe not easy, but doable in principle, I think.

> BTW, inner classes have some trouble with serialUID.

Hmm, could you explain that too? Inner classes are normal classes at
the JVM level...

Regards,
Alessio