Serialization

[Peter Jones]

Hi,

On Dec 11, 2009, at 12:31 AM, Mark Reinhold wrote:

>> Date: Thu, 10 Dec 2009 23:20:51 +0100
>> From: Patrick Wright <pdoubleya at gmail.com>
>
>> May we assume that there will be nothing about how closures are
>> implemented that would prevent fields of function types in
>> serializable classes?
>
> Good question; I hadn't yet thought about this issue.
>
> For a closure to be serializable would require all the values it
> references to be serializable, including "this" if it captures its
> enclosing instance.  If that's true then offhand I don't see any
> other problems and it should "just work".
>
> (Serialization is tricky though, so I may well be missing something.)

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.

And of course, for it to just work, the closure object's class would  
have to implement Serializable.

-- Peter