Bill, Antonio,
As Antonio said in CDI 2.0 we’ll need an @Asynchronous-ish annotation. The asynchronous features we plan to add are in in the Java 8 spirit and will deal more with CompletionStage than Future. So it could be a good idea to have a different name than @Asynchronous for this feature. This will avoid end user confusion with this new @Asynchronous and the one in EJB (like we have today with CDI @Produces and Jax-RS @Produces). So it will be more an @Async annotation (to stick with method naming in CompletableFuture).
Regarding where to put this annotation, I think that JSR 250 could be a nice place. My only concern is that JSR 250 in Java SE is not the same than Java EE. In Java 8 javax.annotaion contains only a subset of JSR 250 1.1 (Java EE 6 version). So we could have issues in using new or modified annotation of JSR 250 in Java SE.
Since the concurrency utilities spec is very EE oriented, I’m against having a dependency on it at the spec level since it will be useless in Java SE.
Antoine
> Le 19 déc. 2014 à 21:15, Bill Shannon <bill.shannon_at_oracle.com> a écrit :
>
> If it seems like we're going to have multiple specifications, each defining their own notion of "asynchronous", and yet their notions of asynchronous are similar enough that it makes sense to have a common annotation to indicate that, we could certainly consider adding an @Asynchronous annotation to the Common Annotations spec.
>
> But, we're not going to rework EJB to use that annotation; it already has its own.
>
> If CDI defines it for all CDI beans, what other specs would need to define it for what use cases? Why wouldn't all those other specs just depend on the thing they want to invoke asynchronously being a CDI bean?
>
> Maybe the CDI implementation of @Asynchronous needs to be different when running on SE vs. EE, but would users of CDI need to know that?
>
> Why wouldn't it be sufficient for CDI to define its own @Asynchronous annotation and have everything else that needed asynchronous method invocation depend on CDI?
>
>
> Antonio Goncalves wrote on 12/19/14 01:51:
>>
>> Hi,
>>
>> So let me bring a related issue.
>>
>> The CDI 2.0 EG is considering adding assynchronous method invocation (using a @Asynchronous annotation). CDI is also targetting Java SE integration (like JPA and so on, by using a CDI container factory). This means that @Asynchronous methods need to work in both Java SE and Java EE.
>>
>> Would is make sense to have @Asynchronous in JSR 250 and, this way, rely on a Java SE implementation (in CDI 2.0) and a Java EE implementation (let's say EE Concurreny) ?
>>
>> I suppose the underlying question is "Could we create standard annotations that will have SE and EE behaviour in JSR 250" ? I'm thinking of @RolesAllowed, for example, that could have a SE and EE implementation.
>>
>> Antonio
>>
>>
>> On Mon, Dec 15, 2014 at 11:47 PM, Bill Shannon <bill.shannon_at_oracle.com <mailto:bill.shannon_at_oracle.com>> wrote:
>> We agree on the long term vision. This is almost entirely a resource issue. In order to do this, we have to stop doing something else, or we have to delay the release. Based on the feedback we've gotten from the community, the things we've chosen to work on right now are the most important. We'd like to do what you suggest below as well, but it's most likely going to have to be done later.
>>
>> Note also that the Concurrency spec wasn't conceived as "anything related to any kind of concurrency in Java EE". Whether it should become that is a question we'll have to answer in the future when we deal with these issues.
>>
>> Antonio Goncalves wrote on 12/15/14 14:09:
>>> Hi all,
>>>
>>> Concurrency Utilities for Java EE (JSR 236) : It would be the perfect spec to have @Startup, @Schedule, @Asynchronous, @Pooled annotations. Any plans on that ?
>>> > We are still evaluating whether there will be a new JSR/MR.
>>>
>>> I think that is one of my biggest concern. I don't know what is the middle to long time "vision" of Java EE, but I think that what happened with @Transactional in JTA should be replicated : @TransactionalAttribute in EJB was fine, but it makes more sense to have this concern going back to JTA. @Asynchronous, @Startup, @Schedule should "leave" the EJB spec to go back where it belongs. @Pooled would also make sense. Plus, if we want to embrace Java SE 8, there are new asynchronous APIs that Java EE should leverage, and again, going to the Concurrency spec would make sense.
>>>
>>> What could we do to work on the process of evaluating if Concurrency should be updated or not ?
>>>
>>> Antonio
>>>
>>> On Thu, Dec 11, 2014 at 10:46 PM, Linda DeMichiel <linda.demichiel_at_oracle.com <mailto:linda.demichiel_at_oracle.com>> wrote:
>>> Hi Antonio, all,
>>>
>>> Please see inline below....
>>>
>>>
>>> On 12/10/14 8:20 AM, Antonio Goncalves wrote:
>>>> Hi all,
>>>>
>>>> I was wondering if Java EE 8 was "spec completed" at the moment or if there are other specs coming along. Correct me if I'm wrong, but so far we have (I hope I'm not missing any) :
>>>>
>>>> New Specifications
>>>> JCache (JSR 107)
>>>> JSON-B 1.0 (JSR 367)
>>>> MVC 1.0 (JSR 371)
>>>> Java EE Security 1.0 (JSR 375)
>>> These new specifications will of course need to be approved by the
>>> Java EE 8 Expert Group in order to be included in the platform.
>>>> Updated Specifications
>>>> CDI 2.0 (JSR 365)
>>>> JMS 2.1 (JSR 368)
>>>> Servlet 4.0 (JSR 369)
>>>> JAX-RS 2.1 (JSR 370)
>>>> JSF 2.3 (JSR 372)
>>>> Java EE Management API 2.0 (JSR 373)
>>>> JSON-P 1.1 (JSR 374)
>>> Yes
>>>> Any other coming along ?
>>> Our main focus will be on the JSRs listed above. Our JSRs/MRs
>>> covered below will be done more opportunistically, based on
>>> available resources.
>>>> Bean Validation (JSR 349) : I know Emmanuel Bernard is planning of updating it to have the Java SE 8 goodies
>>>> Common Annotations (JSR 250) : The CDI 2.0 EG is thinking of introducing a broader usage of the @Priority annotation (not just for interceptor, but other things). Is there any plan to update the JSR 250 ?
>>> We will do an MR for Common Annotations if needed for alignment with other specifications.
>>>> Concurrency Utilities for Java EE (JSR 236) : It would be the perfect spec to have @Startup, @Schedule, @Asynchronous, @Pooled annotations. Any plans on that ?
>>> We are still evaluating whether there will be a new JSR/MR.
>>>> Enterprise JavaBeans (JSR 345) : The CDI 2.0 is thinking of introducing the notion of self injection (e.g. @Self<MySelf> me) that would allow interception within the same bean. Updating the Interceptor spec could be interesting. Any plans ? If Interceptor is updated, would EJB be updated too ?
>>> We expect that both EJB and Interceptors will need to undergo an MR
>>> to align with work being done in related JSRs.
>>>> Java Persistence 2.1 (JSR 338) : any plan to support Date and Time API (JSR 310) mapping ? Is there a MR planned for JPA ?
>>> We expect JPA to undergo an MR. I don't know at this point whether
>>> Date/Time will be addressed.
>>>> Java API for WebSocket (JSR 356) : just wondering
>>> There will be a new JSR or MR for WebSocket. We are currently evaluating which.
>>>> Batch (JSR 352) : just wondering
>>> I'll let our IBM expert speak to this....
>>>>
>>>> Data Grids (JSR 347) : just wondering
>>> I'll let our Red Hat expert speak to this....
>>>>
>>>> Expression Language 3.0 (JSR 341) : just wondering
>>> MR
>>>> JAX-WS 2.0 (JSR 224) : just wondering
>>> MR (likely only to support repeating annotations).
>>>
>>> In addition, we are planning to do MRs for JTA and JavaMail.
>>>
>>>
>>> -Linda
>>>
>>>>
>>>>
>>>> Thanks for any feedback
>>>>
>>>> --
>>>> Antonio Goncalves
>>>> Software architect, Java Champion and Pluralsight author
>>>>
>>>> Web site <http://www.antoniogoncalves.org/> | Twitter <http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> | Pluralsight <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris JUG <http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/>
>>>
>>>
>>> --
>>> Antonio Goncalves
>>> Software architect, Java Champion and Pluralsight author
>>>
>>> Web site <http://www.antoniogoncalves.org/> | Twitter <http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> | Pluralsight <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris JUG <http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/>
>>
>>
>> --
>> Antonio Goncalves
>> Software architect, Java Champion and Pluralsight author
>>
>> Web site <http://www.antoniogoncalves.org/> | Twitter <http://twitter.com/agoncal> | LinkedIn <http://www.linkedin.com/in/agoncal> | Pluralsight <http://pluralsight.com/training/Authors/Details/antonio-goncalves> | Paris JUG <http://www.parisjug.org/> | Devoxx France <http://www.devoxx.fr/>