Serialization stability and naming (and syntax)

[Sam Pullara]

On Sep 30, 2012, at 7:43 AM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> Example: order of capture.  Suppose we have a lambda 
>  x -> (capA < capB) ? x : 0;
> 
> If this is refactored into
> 
>  x -> (capB >= capA) ? 0 : x;
> 
> as your IDE will happily do for you, you've broken serialized instances.  If the compiler picks a stable algorithm at all for assigning captured values to indexed slots, it will probably be something like "the order in which the captured vars appear in the body."  

Something similar would happen for renames even if we introduced a stable sort order.

> The bottom line is that there are so many ways that we can break eisting serialized instances -- even more than with inner classes.  The target profile we set at the outset -- serialization works when you have bytecode-identical classes on both sides -- is really the only thing that is guaranteed to work.  
> 
> Eliminate one source of instability -- the name -- yields only a minor improvement.  If we care about name stability, perhaps we should spend the effort on a better naming scheme than lambda$nnn, one that is less sensitive to small changes into the source code.  

I don't think we will get better than "the same code on both sides of the wire works" which is all anyone has had to date with serialization anyway. I propose that you put in the method name and then number them. That might even be useful in a stack trace when debug is off.

lamba$method$nnn

You can change this for inner classes as well. Whatever syntax is proposed I would like some use case for it that isn't Serialization since I will never use Serialization and would vote not to do it at all if that was tenable. So, things where you can implement tagging interfaces or apply annotations are preferable to me.

Sam