<div dir="ltr">Actually I have a PR that will go in before the 8.2 Final release that uses this [1].  Specifically check out the ClusterExecutor interface.  It doesn&#39;t have the issues of streams with overloading existing methods, however it adds both overloaded variants and you can see how the tests invoke those.<div><br></div><div>[1] <a href="https://github.com/infinispan/infinispan/pull/4008">https://github.com/infinispan/infinispan/pull/4008</a><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Feb 17, 2016 at 3:23 AM Galder Zamarreño &lt;<a href="mailto:galder@redhat.com">galder@redhat.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Will,<br>
<br>
A very interesting discovery!<br>
<br>
Do you have a branch were you&#39;ve tried this out? I&#39;d like to play with it to see it in action and analyse the downsides more closely.<br>
<br>
Cheers,<br>
--<br>
Galder Zamarreño<br>
Infinispan, Red Hat<br>
<br>
&gt; On 9 Feb 2016, at 17:36, William Burns &lt;<a href="mailto:mudokonman@gmail.com" target="_blank">mudokonman@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; I wanted to propose a pretty simple way of making the lambdas serializable by default that I stumbled upon while working on another issue.<br>
&gt;<br>
&gt; 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 &quot;specific&quot; one.  Specific in this case you can think of if I can cast one argument type to the other but it can&#39;t be cast to this type, then this one is most specific.<br>
&gt;<br>
&gt; Here is an example, given the following class<br>
&gt;<br>
&gt; interface SerializableFunction&lt;T, R&gt; extends Serializable, Function&lt;T, R&gt;<br>
&gt;<br>
&gt; The stream interface already defines:<br>
&gt;<br>
&gt;    Stream map(Function&lt;? super T, ? extends R&gt; mapper);<br>
&gt;<br>
&gt; But we could add this to the CacheStream interface<br>
&gt;<br>
&gt;   CacheStream map(SerializableFunction&lt;? super T, ? extends R&gt; mapper);<br>
&gt;<br>
&gt; 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&#39;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>
&gt;<br>
&gt; This allows anyone using our Cache interface to immediately get lambdas that are Serializable when using Streams.<br>
&gt;<br>
&gt; 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&#39;t have to implement Serializable then.<br>
&gt;<br>
&gt; What do you guys think?  It seems like a decent compromise to me.<br>
&gt;<br>
&gt;  - Will<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; [1] <a href="https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.12.2.5" rel="noreferrer" target="_blank">https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.12.2.5</a><br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; infinispan-dev mailing list<br>
&gt; <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
&gt; <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
<br>
<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a></blockquote></div></div></div>