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

Sun Mar 6 12:41:12 EST 2016

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.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160306/1082af7b/attachment.html 