[cdi-dev] async: back to completion future?

[Reza Rahman]

I think this is a very bad idea. It's better not to use either API and wait to sort out how CompletableFuture can be used in EE consistently. Because of backwards compatibility rules, it is better to have no API than a bad API.

> On Mar 7, 2016, at 3:45 AM, Romain Manni-Bucau <rmannibucau at gmail.com> wrote:
> 
> 2016-03-07 9:07 GMT+01:00 Martin Kouba <mkouba at redhat.com>:
>> 
>> Dne 7.3.2016 v 09:03 Romain Manni-Bucau napsal(a):
>>> 
>>> Le 7 mars 2016 08:35, "Martin Kouba" <mkouba at redhat.com
>>> <mailto:mkouba at redhat.com>> a écrit :
>>>  >
>>>  > Dne 6.3.2016 v 15:39 Romain Manni-Bucau napsal(a):
>>>  >
>>>  >> Hi guys,
>>>  >>
>>>  >> as a user having a ComlpetionStage makes me loose some JDK utilities,
>>>  >> can we move back to CompletionFuture?
>>>  >>
>>>  >> It would allow for instance:
>>>  >>
>>>  >> // doesn't work with CompletionStage
>>>  >> CompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...))
>>>  >>        .then(...)
>>>  >
>>>  >
>>>  > Well, this should work if the underlying CompletionStage impl
>>> supports toCompletableFuture(), i.e. in Weld 3:
>>>  >
>>> 
>>> Yes but it is not natural to convert it IMO = we can do better
>>> 
>>>  > CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(),
>>> event2.fireAsync(...).toCompletableFuture())
>>>  >
>>>  > AFAIK the default async execution facility of CompletableFuture is
>>> ForkJoinPool.commonPool() which is not a good fit for Java EE. Using the
>>> CompletionStage interface allows us to wrap the async calls without the
>>> specified executor (e.g. CompletionStage.thenApplyAsync(Function<? super
>>> T, ? extends U>)) and supply a default one provided by the impl.
>>>  >
>>> 
>>> Should use the pool in which the evznt is fired then "then step" is
>>> synchronous is my sample so all is decided at fire time
>> 
>> I don't talk about your particular example - I understand that it's not using async exec (although the "then()" method does not exist).
>> 
> 
> was supposed to represent the different flavours (thenRun, thenCompose, ...) ;).
> 
> That said I agree on the state switching the pool is better but with these 2 notes:
> 
> - could be better to hide these poorly designed methods then -> don't use CompletionXXX but a CDI API with a bridge to CompletionX to let the user go back on SE tools
> - we still don't have a *standard* config for the pool(s) underlying CDI features so it sounds as poor as SE solution IMO (at least a core/max/ttl config in beans.xml)
>  
>>> 
>>>  >
>>>  >>
>>>  >> Romain Manni-Bucau
>>>  >> @rmannibucau <https://twitter.com/rmannibucau> | Blog
>>>  >> <http://rmannibucau.wordpress.com> | Github
>>>  >> <https://github.com/rmannibucau> | LinkedIn
>>>  >> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>>>  >> <http://www.tomitribe.com>
>>>  >>
>>>  >>
>>>  >>
>>>  >> _______________________________________________
>>>  >> cdi-dev mailing list
>>>  >> cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
>>>  >> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>  >>
>>>  >> Note that for all code provided on this list, the provider licenses
>>> the code under the Apache License, Version 2
>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
>>> provided on this list, the provider waives all patent and other
>>> intellectual property rights inherent in such information.
>>>  >>
>>>  >
>>>  > --
>>>  > Martin Kouba
>>>  > Software Engineer
>>>  > Red Hat, Czech Republic
>>> 
>> 
>> -- 
>> Martin Kouba
>> Software Engineer
>> Red Hat, Czech Republic
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160307/db1b3110/attachment.html