It seems useful to point out for reference that there are actually a few
EJB APIs that fall under the general "declarative concurrency services"
bucket that I and others had chimed in on some time ago with mixed
results thus far in terms of component model reform. Perhaps they are
indeed a lesser priority now, but I certainly thought they were very
important to broadening the adoption of Java EE when I had filed them:
* @Asynchronous:
https://java.net/jira/browse/EJB_SPEC-3
* @Schedule:
https://java.net/jira/browse/EJB_SPEC-1,
https://java.net/jira/browse/EJB_SPEC-107
* TimerService:
https://java.net/jira/browse/EJB_SPEC-2
* @Lock, @AccessTimeout:
https://java.net/jira/browse/EJB_SPEC-4
* @Pooled/@MaxConcurrency:
https://java.net/jira/browse/EJB_SPEC-113,
https://java.net/jira/browse/EJB_SPEC-9
On 12/15/2014 5:09 PM, Antonio Goncalves wrote:
> 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>