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

Mon Mar 7 05:33:15 EST 2016

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/5520e122/attachment.html 