jjb at google.com
Wed Dec 16 08:51:24 PST 2009
Compiler can generate static class if closure doesn't capture any instance
> variables of the enclosing class and doesn't call any instance methods of
> the enclosing class and doesn't use "this" keyword. Capturing local
> variables does not prevent compiler from generating static class.
> I wouldn't prevent serializability of non-static closures though. If one
> should be worried about that, the compiler could issue a special warning
> that is opt-in type (accompanied with annotation for the same purpose).
I'm not sure where the compiler would issue the warning: serialization is
not a language feature; it's accomplished by invoking a method. The
compiler may have no indication that the object being serialized is of a
function type. I agree that it's inconsistent with our current approach to
serialization (where we do let people serialize instances of non-static
nested classes), but it's usually a mistake when people do it.
> What is important I think is that generated closure class uses the same
> names for it's fields as the names of corresponding captured local
> variables. This way the serialization format stays the same if the set of
> capcured local variables does not change (regardles of the inner
> rearrangements of closure's code). Renaming a captured local variable then
> has the same effect for serialization format of the closure as renaming an
> instance variable has for a normal class.
Agreed. I see this as necessary but not sufficient, though.
More information about the lambda-dev