Serialization

[Peter Levart]

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

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
> >>
> >>     
> >
> >   
> 
> 
>