<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">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. <br>
<br>
On 2016-02-09 11:36 AM, William Burns wrote:<br>
</div>
<blockquote
cite="mid:CA+YCuUNNnxM9tfS4rRb-TR+u2twEWJtmof44G_=2oVGXtjUhrw@mail.gmail.com"
type="cite">
<div dir="ltr">I wanted to propose a pretty simple way of making
the lambdas serializable by default that I stumbled upon while
working on another issue.
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Here is an example, given the following class<br>
<br>
</div>
<div>interface SerializableFunction<T, R> extends
Serializable, Function<T, R><br>
</div>
<div><br>
</div>
<div>The stream interface already defines:<br>
</div>
<div><br>
</div>
<div> Stream map(Function<? super T, ? extends R>
mapper);</div>
<div><br>
</div>
<div>But we could add this to the CacheStream interface<br>
</div>
<div><br>
</div>
<div> CacheStream map(SerializableFunction<? super T, ?
extends R> mapper);</div>
<div><br>
</div>
<div>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.<br>
<br>
</div>
<div>This allows anyone using our Cache interface to immediately
get lambdas that are Serializable when using Streams.<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>What do you guys think? It seems like a decent compromise
to me.<br>
</div>
<div><br>
</div>
<div> - Will<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>[1] <a moz-do-not-send="true"
href="https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.12.2.5"
target="_blank">https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.12.2.5</a><br>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
infinispan-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/infinispan-dev">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a></pre>
</blockquote>
<br>
</body>
</html>