An update:
Lambda arguments are captured at serialization time, this is a good
thing! A static method is generated by the compiler on the enclosing
class and this is called during deserialization.
I'm investigating how to capture the lambda receipe, so that it and it's
arguments can be serialized, without requiring the enclosing class, so
the lambda receipe can be used to create an object independant of it's
original enclosing class during deserialization.
Will keep you posted.
Any thoughts appreciated.
Regards,
Peter.
On 9/03/2014 11:41 AM, Peter Firmstone wrote:
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.