The present serialized form of Lambda's don't access captured fields
until after deserialization, making them dependant on the enclosing
classes serial form, its deserialized object state and requiring the
enclosing class to be Serializable.
This appears to be a fundamental mistake in the design of lambda
serialization.
I don't believe this will be changed now, this decision is the result of
an expert group and the release date for Java 8 draws near.
One possibility of fixing this is to create a marker interface, eg
DistributedLambda.
By implementing a new serialization proxy for DistributedLambda that
doesn't refer to the enclosing class, but instead captures fields at the
time of serialization instead of after deserialization, we can provide
independant short lived functional immutable objects, enabling lambda
parameter arguments for remote objects that don't require codebase
downloads at the exporting node.
My reasoning and consequences:
1. Anonomous classes introduce brittleness in a distributed
environment, they really should be avoided.
2. Capturing state at the time of execution from deserialized
encapsulating object state, invites mutability and side effects
that diverge from the state of the original caller object and
intent of functional programming.
3. Storing a lambda into a @serialField within a Serializable object,
would also mean that the lamdba parameters would be captured at
the time of serialization, not at some later point of execution
after deserialization, so a DistributedLambda wouldn't see updates
to the encapsulating object after deserialization.
4. Lamdba's are functional programming constructs and functional
programming is founded on immutability, so DistributedLambda would
honour that heritage.
5. A DistributedLambda instance becomes an independant immutable
implementation of a functional interface at the time of
serialization, to avoid surprises, fields referred to by a lambda
should be effectively final and side effects should be avoided.
Thoughts?
Regards,
Peter.
