river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject DistributedLambda
Date Sun, 09 Mar 2014 01:41:46 GMT
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 

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 

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.




View raw message