What hazardous hypothesis? Someone that needs a custom executor will need to deal with one
anyway - whether by needing to pass it to the observer dispatcher or the
CompletableFuture.
CompletionStage is the obscure parent superinterface for the CompletableFuture gateway
API. Hence it is mostly functionally equivalent. What's so surprising about that?
What I find strangest about this, is that you started with CompletableFuture yourself:
.
You should already understand the issue of familiarity for that reason alone. If
CompletionStage is so great why didn't you write about it? You are hardly alone. Look
at pretty much everyone that speaks or write on the topic. They all start with
CompletebleFuture unsurprisingly.
Let's stop the polemic and be reasonable. Otherwise we risk having another bad API in
Java EE for no good reason.
Sent from my iPhone
On Mar 7, 2016, at 5:26 PM, Romain Manni-Bucau
<rmannibucau(a)gmail.com> wrote:
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> a écrit :
>
> What is still true for CompletionStage? As I've indicated, it's largely 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.
>
> Let's kindly not argue in circles or repeat ourselves needlessly. It
accomplishes nothing productive.
>
> On Mar 7, 2016, at 5:07 PM, Romain Manni-Bucau <rmannibucau(a)gmail.com> wrote:
>
>> Side note: this is still true for CompletionStage.
>>
>> Le 7 mars 2016 22:48, "Reza Rahman" <reza_rahman(a)lycos.com> a
écrit :
>>>
>>> Not sure how alias works, so resending directly. Responses inline.
>>>
>>> The bottom line is that we should think about the usability of the most
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.
>>>
>>> On Mar 7, 2016, at 4:38 PM, Reza Rahman <reza_rahman(a)lycos.com>
wrote:
>>>
>>>> Responses in-line.
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Mar 7, 2016, at 4:24 PM, Romain Manni-Bucau
<rmannibucau(a)gmail.com> wrote:
>>>>
>>>>>
>>>>> 2016-03-07 22:09 GMT+01:00 Reza Rahman
<reza_rahman(a)lycos.com>:
>>>>>>
>>>>>> Responses in-line.
>>>>>>
>>>>>> On Mar 7, 2016, at 3:35 PM, Romain Manni-Bucau
<rmannibucau(a)gmail.com> wrote:
>>>>>>
>>>>>>>
>>>>>>> 2016-03-07 20:53 GMT+01:00 Reza Rahman
<reza_rahman(a)lycos.com>:
>>>>>>>>
>>>>>>>> Yes, this can be done with a CompletableFuture that has
already been constructed - just take a look at the API.
>>>>>>>>
>>>>>>>
>>>>>>> so - just to try to ensure we speak about the same thing:
>>>>>>>
>>>>>>> asyncEvent.fireAsync(...).thenRunAsync(() -> ...,
eePool); ?
>>>>>>
>>>>>>
>>>>>> Correct.
>>>>>>
>>>>>>>
>>>>>>> This works but has the drawback to not reuse the observer
thread
>>>>>>
>>>>>>
>>>>>> Why would this matter to the average business code developer?
All this would run from managed executors of some kind or the other anyway...
>>>>>>
>>>>>>> and keep the original issue: the observer doesn't
inherit from the caller context so it would likely be:
>>>>>>>
>>>>>>> asyncEvent.fireAsync(..., eePool).thenRunAsync(() -> ...,
eePool);
>>>>>>
>>>>>>
>>>>>> Again, why does it matter really? The observer threads
themselves 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.
>>>>>>
>>>>>
>>>>> Cause it is important to state which thread context is there to keep
the integration with other frameworks - think to security ones in particualr - smooth and
doable.
>>>>
>>>>
>>>> For framework developers usability is hardly a concern. If they need to
preserve their own context they can simply pass in their own managed executor to both the
observer thread and the CompletableFuture.
>>>>
>>>> In the end, the primary focus should be the masses that we hope will
adopt CDI into their applications. Making things harder for them to achieve some limited
SPI goal is pretty dangerous.
>>>>
>>>>>>>
>>>>>>> which looks weird since you trigger 2 tasks where you
actually want just one in another thread originally?
>>>>>>
>>>>>>
>>>>>> I don't follow. Whichever executor service you would use,
ultimately there are at least three different threads associated here in all cases.
>>>>>>
>>>>>>>
>>>>>>> asyncEvent.fireAsync(..., eePool).thenRunAsync(() ->
...); // in the fire async thread
>>>>>>
>>>>>>
>>>>>> You mean using the same executor? Why does this matter really?
They are all managed executors anyway. At best it's reducing one method parameter.
>>>>>>
>>>>>
>>>>> Cause very few apps are 100% EE in practise, probably never will be
and even if so JavaEE security is not integrated (yet?) at this level.
>>>>
>>>>
>>>> There is no such thing as context propagation outside of EE managed
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.
>>>>
>>>>>>> Are
>>>>>>> This last proposal works not that bad if context propagation
would 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.
>>>>>>>
>>>>>>>>
>>>>>>>> As far as not adding it to CDI, I can see either way.
What was the original motivation for adding CompletableFutures?
>>>>>>>>
>>>>>>>> Also, it's a good idea to run this by the platform
expert group. I know at least JAX-RS is planning to use CompletableFutures for their
client API.
>>>>>>>>
>>>>>>>> On Mar 7, 2016, at 2:39 PM, Romain Manni-Bucau
<rmannibucau(a)gmail.com> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2016-03-07 20:35 GMT+01:00 Reza Rahman
<reza_rahman(a)lycos.com>:
>>>>>>>>>>
>>>>>>>>>> Talking with a colleague about this he reminded
me of an 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.
>>>>>>>>>>
>>>>>>>>>> Basically this means CompletableFutures are
already pretty Java EE ready.
>>>>>>>>>>
>>>>>>>>>> If this is the main cited reason for using
CompletionStage, is 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?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Did he mention it is true for *created* comlpetion
future which 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*.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mar 7, 2016, at 8:11 AM, Reza Rahman
<reza_rahman(a)lycos.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> 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(a)gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> 2016-03-07 9:07 GMT+01:00 Martin Kouba
<mkouba(a)redhat.com>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Dne 7.3.2016 v 09:03 Romain
Manni-Bucau napsal(a):
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Le 7 mars 2016 08:35,
"Martin Kouba" <mkouba(a)redhat.com
>>>>>>>>>>>>>>
<mailto:mkouba@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(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
>>>>>>>>>>>>>> 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(a)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.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> cdi-dev mailing list
>>>>>>>>>> cdi-dev(a)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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> cdi-dev mailing list
>>>>>>>> cdi-dev(a)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.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> cdi-dev mailing list
>>>>>> cdi-dev(a)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.
>>>>>
>>>>>
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev(a)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.
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)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.