Lambdas and serialization

Joe Darcy joe.darcy at oracle.com
Wed Oct 20 08:37:09 PDT 2010


Mark Wielaard wrote:
> On Tue, 2010-10-19 at 15:40 -0700, Bob Lee wrote:
>   
>> On Tue, Oct 19, 2010 at 3:33 PM, Alessio Stalla <alessiostalla at gmail.com>wrote:
>>
>>     
>>> Well, but then the serializable form of any java.* class is not
>>> necessarily compatible between different JVMs, again because the
>>> internal details might be different. Default serialization is not
>>> meant as a standard storage format, rather as a means to store a graph
>>> of objects into a sequence of bytes and restore it later *using the
>>> same JVM*.
>>>       
>
>   
>> That's actually not true. If a class is serializable, its serialized form is
>> part of the published API, and you are guaranteed compatibility across VMs
>> and VM versions.
>>     
>
> But not all serialized forms are published. For example it is not
> specified how precisely an inner class is transformed to byte code
> (compiler generated methods/fields can have different names) so using
> different java source to byte code compilers might result in different
> serialized forms. 

Or even different versions of the same compiler or the same compiler 
with seemingly independent modifications to the source file (anonymous 
classes are numbered).  How an anonymous class is compiled is a 
compiler-internal contract.

> And sometimes constructs use (undocumented) internal
> implementation classes for serialization like Annotations (which uses
> sun.reflect.annotation which isn't guaranteed to be compatible across
> independent implementations).
>   

It was a bug that annotations used a sun.* class in their serialized form.

-Joe


More information about the lambda-dev mailing list