<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>If still in doubt, a wise move on this is to seek guidance from the JDK team. We shouldn't be doing things contrary to what their API design intent is. Their API design positioning is what folks out there are picking up and running with.</div><div><br>On Mar 7, 2016, at 8:22 AM, Reza Rahman <<a href="mailto:reza_rahman@lycos.com">reza_rahman@lycos.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>If you don't understand why most developers would simply expect to use CompletableFuture and would immediately be confused if they see something else, I think we are in bigger trouble than I thought.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">You should really ask a few developers outside your immediate network or do a Google search to see just how much more prominent CompletableFuture is as oppose to CompletionStage. Not finding a way to use that API and choosing an obscure superclass is a sure recipe for problems.</div><div><br>On Mar 7, 2016, at 5:12 AM, Antoine Sabot-Durand <<a href="mailto:antoine@sabot-durand.net">antoine@sabot-durand.net</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><span style="font-size:13px;line-height:19.5px">Hi guys,</span><div style="font-size:13px;line-height:19.5px"><br></div><div style="font-size:13px;line-height:19.5px">Back from vacation, I'm "happy" to see that we go back on Async event feature (which took us 6 months).</div><div style="font-size:13px;line-height:19.5px"><br></div><div style="font-size:13px;line-height:19.5px">@Reza and @Romain sorry but I don't get it. the good practice is to develop for interface (that's why CDI uses Set and not HashSet for instance). I'm ok it's the theory, but if you want to make an exception to this practice you need to have a good reason. So if you want to rely on JDK classes like CompletableFuture instead of interface, you'll probably have to go a step further than that. CompletionStage has a toCompletableFuture() method.</div><div style="font-size:13px;line-height:19.5px"><br></div><div style="font-size:13px;line-height:19.5px">To go back to the big picture, as some people around don't seem to be happy with what we designed, we still have the solution to move async event can in specification annexe. It's a solution to test a feature without definitely specifying it.</div><div style="font-size:13px;line-height:19.5px"><br></div><div style="font-size:13px;line-height:19.5px">Antoine</div><br><div class="gmail_quote"><div dir="ltr">Le lun. 7 mars 2016 à 08:42, Martin Kouba <<a href="mailto:mkouba@redhat.com">mkouba@redhat.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dne 6.3.2016 v 16:37 Reza Rahman napsal(a):<br>
> How much end user feedback has there been on this? I have to be honest<br>
> that it surprises me to find this out now.<br>
<br>
Well, this was discussed many times (ML, EG mtgs, F2F, etc.).<br>
<br>
><br>
> This to me stands out as an obvious usability problem. CompletableFuture<br>
> is the obvious top level end user API, not CompletionStage.<br>
<br>
Is it obvious? For me the CompletionStage looks more appropriate. But<br>
I'm open for discussions.<br>
<br>
> Not going<br>
> with CompletableFuture is very likely to confuse most people. The last<br>
> thing we need is more potential usability problems in Java EE APIs.<br>
><br>
> On Mar 6, 2016, at 9:39 AM, Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a><br>
> <mailto:<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>>> wrote:<br>
><br>
>> Hi guys,<br>
>><br>
>> as a user having a ComlpetionStage makes me loose some JDK utilities,<br>
>> can we move back to CompletionFuture?<br>
>><br>
>> It would allow for instance:<br>
>><br>
>> // doesn't work with CompletionStage<br>
>> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...))<br>
>> .then(...)<br>
>><br>
>> Romain Manni-Bucau<br>
>> @rmannibucau <<a href="https://twitter.com/rmannibucau" rel="noreferrer" target="_blank">https://twitter.com/rmannibucau</a>> | Blog<br>
>> <<a href="http://rmannibucau.wordpress.com" rel="noreferrer" target="_blank">http://rmannibucau.wordpress.com</a>> | Github<br>
>> <<a href="https://github.com/rmannibucau" rel="noreferrer" target="_blank">https://github.com/rmannibucau</a>> | LinkedIn<br>
>> <<a href="https://www.linkedin.com/in/rmannibucau" rel="noreferrer" target="_blank">https://www.linkedin.com/in/rmannibucau</a>> | Tomitriber<br>
>> <<a href="http://www.tomitribe.com" rel="noreferrer" target="_blank">http://www.tomitribe.com</a>><br>
>> _______________________________________________<br>
>> cdi-dev mailing list<br>
>> <a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a> <mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
>><br>
>> Note that for all code provided on this list, the provider licenses<br>
>> the code under the Apache License, Version 2<br>
>> (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas<br>
>> provided on this list, the provider waives all patent and other<br>
>> intellectual property rights inherent in such information.<br>
><br>
><br>
> _______________________________________________<br>
> cdi-dev mailing list<br>
> <a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
><br>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br>
><br>
<br>
--<br>
Martin Kouba<br>
Software Engineer<br>
Red Hat, Czech Republic<br>
_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
<br>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br>
</blockquote></div></div>
</div></blockquote></div></blockquote></body></html>