Serialization

[Joshua Bloch]

Peter,

I agree with everything you way.  I just wanted to point out a specific case
where we do serialize function objects to show that this has practical
consequences.

               Josh

On Mon, Dec 21, 2009 at 6:11 AM, Peter Jones <pcj at roundroom.net> wrote:

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