Serialization

[Joshua Bloch]

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