[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