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

Romain Manni-Bucau rmannibucau at gmail.com
Mon Mar 7 08:02:56 EST 2016 

2016-03-07 13:57 GMT+01:00 John D. Ament <john.d.ament at gmail.com>:

> Antoine,
>
> I don't think we have vastly differing opinions here.  My main concern is
> that the CDI Impls wait for the spec to say something should be done before
> implementing.  There is very little innovation that happens within the
> implementations, as a result its very hard for the EG to decide how
> something should work - you have anywhere from 0 to 1 capabilities existing
> in the wild to see how it should behave.
>
>
Sadly it is like that and guess will stay cause spec are used for standards
and any innovation doesn't make users happy if at programming level (it is
on ops side) - and believe me I say it after having tried very hard the
other way around.


> And actually I'll disagree pretty heavily about how CDI came to be.  Most
> of what was Seam 2 went into WebBeans.  The CDI behaviors were adapted from
> Seam 2 from a DI stand point, with some clean up with where there were
> gaps, things that didn't make sense, and things that just didn't belong.
>
>
That's the way which works the best: you do something outside spec umbrella
(including "official implementations") then you standardize it. DeltaSpike
is a good example of it: no impl shadow but new proposals which could be
standardized as Seam has been.


> John
>
>
> On Mon, Mar 7, 2016 at 5:33 AM Antoine Sabot-Durand <
> antoine at sabot-durand.net> wrote:
>
>> John, I partially disagree with you here.
>>
>> CDI innovated from the beginning. When the project started in 2007 there
>> wasn't any strong typed DI framework around. No spec proposed a SPI like
>> CDI and eventing system in DI framework were inexistant or nearly unused
>> (Who eared of event bus in Spring ?). Following your definition of what is
>> a specification CDI wouldn't be here today.
>>
>> The challenge is to find a real balance between innovating (but not to
>> much and without breaking backward compatibility) and take working ideas
>> around in impl or other framework (like builders from DeltaSpike or Weld
>> bootstrap API that we are about to propose to complete SE API)
>>
>> The problem with CDI, is that it's still limited to Java EE so you'll
>> only have very few user giving you feedback on impl specific features. It
>> will probably change when we'll add SE support but in the meantime we
>> should try to deliver something useful for our users and something they
>> asked (like async events).
>>
>> As I said in my previous mail, Spec annexe can be used to put features
>> that didn't gather enough truct from the EG to be specified. It's a step
>> between spec and impl. Bean validation already done that in 1.0 with method
>> validation
>>
>> http://beanvalidation.org/1.0/spec/#appendix-methodlevelvalidation
>>
>> And standardize it in 1.1 after having gathered users feedback:
>>
>> http://beanvalidation.org/1.1/spec/#d0e267
>>
>>
>> Antoine
>> Le dim. 6 mars 2016 à 18:41, John D. Ament <john.d.ament at gmail.com> a
>> écrit :
>>
>>> On Sun, Mar 6, 2016 at 12:25 PM Romain Manni-Bucau <
>>> rmannibucau at gmail.com> wrote:
>>>
>>>> 2016-03-06 18:02 GMT+01:00 John D. Ament <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.
>>>
>>> - 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.
>>>
>>> - 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>.  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.
>>>
>>> John
>>>
>>>
>>>>
>>>>
>>>>> John
>>>>>
>>>>>
>>>>> On Sun, Mar 6, 2016 at 10:37 AM Reza Rahman <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>
>>>>>> 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
>>>>>> 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.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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.
>>>>>
>>>> _______________________________________________
>>> 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/7767e59c/attachment-0001.html

More information about the cdi-dev mailing list