pcj at roundroom.net
Mon Dec 21 06:11:15 PST 2009
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.
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?
> 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
> > instances of anonymous classes today: that the binary names of
> the classes are
> > neither JLS-determined nor very stable across edits/recompiles.
> > 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
> at least not at the outset. If there turn out to be compelling use
> then we could look in to making them serializable later on.
> - Mark
More information about the lambda-dev