Serialization

[Rémi Forax]

Peter Levart a écrit :
> You don't need to bury that into closure's default serialization logic. You can achieve the same by custom serialization of a class that is a container for a closure. The only service you need from closure is obtaining it's code identification (class name?) and stable serialization of closure's fields. Bytecode can be obtained from closure's class' classloader.
>
> Peter
>   

Yes, but how to have a stable class name ?

Rémi

> On Wednesday 16 December 2009 11:43:35 Rémi Forax wrote:
>   
>> I am affraid that the only solution is to serialize the bytecode of the 
>> lambda expression/statement.
>>
>> Rémi
>>
>> Joshua Bloch a écrit :
>>     
>>> Mark,
>>>
>>> I'm sorry to say, I don't know.  It's a hard problem.  One possibility is to
>>> provide a concise syntax for named singleton subclasses of functional types.
>>>  That would finesse the problem rather than solving it.
>>>
>>>              Josh
>>>
>>> On Tue, Dec 15, 2009 at 10:38 PM, Mark Reinhold <mr at sun.com> wrote:
>>>
>>>   
>>>       
>>>>> Date: Tue, 15 Dec 2009 22:17:41 -0800
>>>>> From: Joshua Bloch <jjb at google.com>
>>>>>       
>>>>> This is a moderately important decision. In Google's Java MapReduce API,
>>>>>       
>>>>>           
>>>> we use
>>>>     
>>>>         
>>>>> SAM interfaces to represent Mapper and Reducer. Instances must be
>>>>>       
>>>>>           
>>>> serializable,
>>>>     
>>>>         
>>>>> as they're serialized to pass them from the node that starts the
>>>>>       
>>>>>           
>>>> MapReduce to
>>>>     
>>>>         
>>>>> the worker nodes (which do the actual mapping and reduction). That means
>>>>>       
>>>>>           
>>>> we
>>>>     
>>>>         
>>>>> won't be able to use closure syntax for MapReduce, which seems like a
>>>>>       
>>>>>           
>>>> shame.
>>>>     
>>>>         
>>>>> This is no worse than what we do with SAM types today, but it's no
>>>>>       
>>>>>           
>>>> better,
>>>>     
>>>>         
>>>>> either. Can we do better?
>>>>>       
>>>>>           
>>>> Maybe.  How would you suggest we address the concerns which Peter raised?
>>>>
>>>> - Mark
>>>>
>>>>     
>>>>         
>>>   
>>>       
>>
>>