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

You can give CompletionStage a pool too. So it helps the other thread bit not this one if we dont make any hazardeous hypothesis. Le 7 mars 2016 23:19, "Reza Rahman" <reza_rahman(a)lycos.com&gt; a écrit : an SPI rather than an end user API like CompletableFuture. For that reason it will never have the level of familiarity that CompletableFuture already does. accomplishes nothing productive. wrote: common end user. If anyone needs custom executor service control in the worst case it's still just a matter of one extra parameter as opposed to introducing an obscure alternative to CompletableFuture. wrote: wrote: been constructed - just take a look at the API. this would run from managed executors of some kind or the other anyway... caller context so it would likely be: should be running from a managed pool that is smart enough to preserve context anyway? If the business developer cares about preserving context in their code, they can use a managed executor themselves on the returned CompletableFuture. the integration with other frameworks - think to security ones in particualr - smooth and doable. to preserve their own context they can simply pass in their own managed executor to both the observer thread and the CompletableFuture. adopt CDI into their applications. Making things harder for them to achieve some limited SPI goal is pretty dangerous. just one in another thread originally? there are at least three different threads associated here in all cases. the fire async thread are all managed executors anyway. At best it's reducing one method parameter. and even if so JavaEE security is not integrated (yet?) at this level. executors. In SE land, the only thing you have is manually writing your own executor to do the same things. These folks will have to pass around their own executors anyway, even to the observer thread. work but since there are cases it would be expected to work and other it shouldn't - from a user point of view auto inheritance can break thread safety - I wonder if it shouldn't be spec-ed. Can be the new API I proposed or even just a new scope close to request scoped but inheritable by design. original motivation for adding CompletableFutures? know at least JAX-RS is planning to use CompletableFutures for their client API. rmannibucau(a)gmail.com&gt; wrote: important fact I almost forgot. The CompletableFuture API can actually be used with custom executors. That means users concerned about managed threads in a Java EE environment can use it with existing EE 7 concurrency executors. EE ready. it really that valid of an argument to justify yet another custom subclass specific only to CDI instead of what's likely to be far more familiar and expected? is not the case for async events? But this is a good point to not add anything to CDI: the feature is a one liner *already*. wrote: 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. rmannibucau(a)gmail.com&gt; wrote: JDK utilities, event2.fireAsync(...)) impl better CompletableFuture.allOf(event1.fireAsync(...).toCompletableFuture(), CompletableFuture is EE. Using the without the CompletionStage.thenApplyAsync(Function<? super impl. step" is that it's not using async exec (although the "then()" method does not exist). thenCompose, ...) ;). but with these 2 notes: -> don't use CompletionXXX but a CDI API with a bridge to CompletionX to let the user go back on SE tools 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(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org> >>>>>>>>>>>>>> >> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>>>>>>>> >> >>>>>>>>>>>>>> >> Note that for all code provided on this list, the provider licenses other ideas other 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. 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. 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. 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. 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. 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.