Serialization

[Peter Jones]

Josh,

I appreciate the desire-- but as you say, it's a hard problem.

I suspect that the way that the serializability of a class defines,  
albeit obliquely, a sort of wire protocol, and the considerations for  
good wire protocol design (something that serialization already makes  
too easy to skimp on!), are somewhat fundamentally at odds with the  
conciseness that motivates the lambda syntax for SAM implementations.   
I'm not sure that this cake can be had and eaten too.  I'd be happy to  
be shown otherwise.

Cheers,
-- Peter


On Dec 16, 2009, at 1:17 AM, Joshua Bloch wrote:

> Mark and Peter,
>
> 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?
>
>           Josh
>
> On Tue, Dec 15, 2009 at 9:26 PM, Mark Reinhold <mr at sun.com> wrote:
> > Date: Mon, 14 Dec 2009 01:23:54 -0500
> > From: Peter Jones <pcj at roundroom.net>
>
> > I expect that there would be the issue that is also a problem with  
> serializing
> > instances of anonymous classes today: that the binary  names of  
> the classes are
> > neither JLS-determined nor very stable across  edits/recompiles.   
> Serialization
> > represents an object's code by its  class's binary name, but these  
> things won't
> > have overt names.   Moreover, the set of a closure's serializable  
> fields seems
> > likely to  be less stable in practice compared to a normally- 
> declared class.
> > And  I don't see how you could specify any of the usual  
> customizations to
> > serialized form or behavior (transient, readObject, etc.).  What  
> these  issues
> > suggest to me is that in cases where the writing and the  reading  
> code are from
> > the exact same compilation of sources, then  perhaps serialization  
> of closures
> > could work and be useful-- but I  don't see it working in the more  
> general case
> > of communication across  an API contract.
>
> Like I said -- serialization is tricky.  Thanks Peter.
>
> Taken together these are good reasons not to make closures  
> serializable,
> at least not at the outset.  If there turn out to be compelling use  
> cases
> then we could look in to making them serializable later on.
>
> - Mark
>
>