[cdi-dev] async: back to completion future?
Martin Kouba
mkouba at redhat.com
Mon Mar 7 03:03:19 EST 2016
Dne 6.3.2016 v 18:41 John D. Ament napsal(a):
>
>
> On Sun, Mar 6, 2016 at 12:25 PM Romain Manni-Bucau
> <rmannibucau at gmail.com <mailto:rmannibucau at gmail.com>> wrote:
>
> 2016-03-06 18:02 GMT+01:00 John D. Ament <john.d.ament at gmail.com
> <mailto:john.d.ament at gmail.com>>:
>
> What I think would be even better is to see this implemented in
> the impls (Weld & OWB) and see how users use it, in a release
> that's not plastered with Alpha or Experimental all over it.
> While I think we were all wary about it, we need real end user
> input from the impl standpoint to figure out what makes sense to
> standardize on.
>
>
> Or just do the opposite and *standardize* it. We can use Rx*
> feedbacks but it doesnt' match event case at all which is a real
> small subset of the reactive programming so I guess easiness should
> be what drives us there and integration at least with the JVM so
> CFuture version sounds more natural than CStage one. Difference is
> very small at method level but at utility level it is.
>
> Side note: a Weld or OWB release without experimental/alpha sounds
> worse if the spec changes later. A compromise can be an extension
> doing it already you can drop in any of these containers.
>
>
> There seems to be a general misunderstanding about how the specs are
> intended to work. You standardize on things that as a group everyone
> has agreed would work in a specific way. Right now, the CDI EG is
> innovating and standardizing on those innovations instead of
> standardizing on the features already available in the various impls.
> Lets take a few examples of where impls deviate from the specs.
>
> - Bean Validation: Hibernate Validator has a suite of built in
> validations
> https://github.com/hibernate/hibernate-validator/tree/master/engine/src/main/java/org/hibernate/validator/constraints -
> these constraints can in theory work in any pluggable environment, but
> come with their core engine built in, for people to leverage. These are
> good targets to leverage in the core spec when its seen as being very
> useful.
I think you cannot compare custom BV constraints and things which
require core API changes.
>
> - JAX-RS : All of the implementations had client impls paired up with
> their 1.1 compliant releases, even though it wasn't required. Why?
> Because it made a ton of sense. Then see what happened afterwards, the
> EG came together and standardized on a Client API that took a lot of the
> great features in each impl and made them consistent.
>
> - EJB: Lets not forget that the removal of home/remote/local interfaces
> came from a combination of xdoclet and spring. The EG came together,
> saw that what was in use and figured out how to standardize on it once
> the language features were available.
>
> - Singleton EJBs: An extension of EJB 3, most vendors supported a form
> of singleton in their EJBs, and the EJB EG agreed upon it in addition to
> some concurrency issues that had to be addressed.
>
> - CDI: Lets not forget about the hard work people like strub have put
> into making CDI work well. Scoped Beans only? Awesome idea.
> https://github.com/apache/openwebbeans/commit/3b3640e17c88e7c095563337194ba23c6f9e1689
> He didn't wait for the EG to standardize on anything before implementing.
You call it "awesome idea", I agree that this feature makes sense, but I
call it "manipulative approach". It was implemented before the EG was
able to decide. The same for CDI-527 - OWB has a config property
"javax.enterprise.inject.allowProxying.classes" but the proposed PR was
not merged. Sure, EG is slow but it doesn't mean it should be ignored.
>
> - JPA: Lets not forget that HIbernate supports in dual hierarchies the
> EntityManager and Session interfaces concurrently. Want to use HQL in
> your @NamedQuery? Sure, it works fine.
>
> Bottom line, we need to get these features out into the wild, let people
> play and come back with input on the various impls. There's nothing
> stopping the weld team from introducing
> org.jboss.weld.events.api.AsyncEvent that supports CompletableFuture and
> CompletionStage, allowing app developers to consume this via an
> injection point just like Event works today, @Inject AsyncEvent<Foo>.
But this would require the users to depend on Weld API! And that's only
acceptable in SE and servlet containers where the users need
impl-specific stuff anyway.
> Even if thats not the spec compliant way to do it long term, it makes it
> clear that you're using a provider specific API.
>
> In addition, there would be nothing stopping either team from
> introducing support for @Priority on observer methods. There's no API
> change, no spec change required. The spec doesn't mandate that it
> works, but there's nothing stopping your impl from allowing it. The
> spec doesn't say you absolutely cannot leverage it.
I agree that the impls should innovate where the spec allows it. On the
hand, it's not always an easy task, esp. if you need backward compatibility.
>
> John
>
> John
>
>
> On Sun, Mar 6, 2016 at 10:37 AM Reza Rahman
> <reza_rahman at lycos.com <mailto:reza_rahman at lycos.com>> wrote:
>
> How much end user feedback has there been on this? I have to
> be honest that it surprises me to find this out now.
>
> This to me stands out as an obvious usability problem.
> CompletableFuture is the obvious top level end user API, not
> CompletionStage. Not going with CompletableFuture is very
> likely to confuse most people. The last thing we need is
> more potential usability problems in Java EE APIs.
>
> On Mar 6, 2016, at 9:39 AM, Romain Manni-Bucau
> <rmannibucau at gmail.com <mailto:rmannibucau at gmail.com>> wrote:
>
>> 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(...)
>>
>> 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.
> _______________________________________________
> 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.
>
>
> _______________________________________________
> 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.
>
>
>
> _______________________________________________
> 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.
>
--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
More information about the cdi-dev
mailing list