river-dev mailing list archives

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


Mime
View raw message