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>