[infinispan-dev] Lambda Serialization

Vladimir Blagojevic vblagoje at redhat.com
Thu Feb 11 14:52:12 EST 2016


I think it does. If we document both approaches nicely *and* give 
examples then users can choose what suits them the most. Target user 
group of this API is likely very knowledgeable group of programmers anyway.

On 2016-02-09 11:36 AM, William Burns wrote:
> I wanted to propose a pretty simple way of making the lambdas 
> serializable by default that I stumbled upon while working on another 
> issue.
>
> I noticed that in the method resolution of the compiler it does some 
> nice things [1].  To be more specific when you have 2 methods with the 
> same name but vary by argument types, it will attempt to pick the most 
> "specific" one.  Specific in this case you can think of if I can cast 
> one argument type to the other but it can't be cast to this type, then 
> this one is most specific.
>
> Here is an example, given the following class
>
> interface SerializableFunction<T, R> extends Serializable, Function<T, R>
>
> The stream interface already defines:
>
>    Stream map(Function<? super T, ? extends R> mapper);
>
> But we could add this to the CacheStream interface
>
>   CacheStream map(SerializableFunction<? super T, ? extends R> mapper);
>
> In this case you have 2 different map methods accessible from your 
> CacheStream instance.  When passing a lambda the Java compiler will 
> automatically choose the most specific one (in this case the 
> SerializableFunction one since Function can't be cast to 
> SerializableFunction).  This will then make the lambda automatically 
> Serializable.  In this way nothing special has to be done (ie. 
> explicit cast) to make the instance Serializable.
>
> This allows anyone using our Cache interface to immediately get 
> lambdas that are Serializable when using Streams.
>
> The main problem however would be ambiguity because the Serialization 
> would only be applied assuming you are using a defined class of 
> CacheStream etc.  Also this means there are 2 methods (but that seems 
> fine to me), so it could cause a bit of confusion.  The non 
> serialization method is still helpful if people want to their own 
> Externalizer, since their implementation doesn't have to implement 
> Serializable then.
>
> What do you guys think?  It seems like a decent compromise to me.
>
>  - Will
>
>
>
>
>
> [1] 
> https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.12.2.5
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160211/4974ecf9/attachment-0001.html 


More information about the infinispan-dev mailing list