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:
Antoine
Le dim. 6 mars 2016 à 18:41, John D. Ament <john.d.ament@gmail.com> a écrit :On Sun, Mar 6, 2016 at 12:25 PM Romain Manni-Bucau <rmannibucau@gmail.com> wrote:2016-03-06 18:02 GMT+01:00 John D. Ament <john.d.ament@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_______________________________________________JohnOn Sun, Mar 6, 2016 at 10:37 AM Reza Rahman <reza_rahman@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._______________________________________________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 CompletionStageCompletionFuture.allOf(event1.fireAsync(...), event2.fireAsync(...)).then(...)_______________________________________________
cdi-dev mailing list
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.
cdi-dev mailing list
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.
_______________________________________________
cdi-dev mailing list
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.
cdi-dev mailing list
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.