Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] [jakartaee-spec-project-leads] AddConcurrency 3.0 to Web Profile?

I guess allowing to use things like @Schedule (along the lines of what Spring and Spring Boot offer in a similar way) sounds like a good idea probably even for the Core Profile with very few or no other dependencies, that should do more good than harm.

 

I did a Java EE 8 Performance Video tutorial a few years ago where I also explained the differences and similarities between Asyc CDI, EJB Concurrency and Concurrency Utilities and especially CDI at the time still was lacking a few concurrency aspects and features in a portable and vendor-neutral way, so even if some of that improved since, I think it could be a good addition.

 

Werner

 

Von: Steve Millidge (Payara)
Gesendet: Donnerstag, 29. Juli 2021 11:45
An: jakartaee-platform developer discussions; JakartaEE Spec Project Leadership discussions
Betreff: Re: [jakartaee-platform-dev] [jakartaee-spec-project-leads] AddConcurrency 3.0 to Web Profile?

 

Let's do the discussion here on this thread then.

 

For those that do not know. Jakarta Concurrency provides developers with the ability to use Java concurrency style primitives  Managed Executors, Managed Threads, Scheduled Executors etc. safely within a Jakarta EE container including propagation of  required Jakarta contexts to the different thread.

 

My reasons for wanting Concurrency in Web and Core profiles.

 

1) The concerns of Jakarta Concurrency are foundational as they deal with using multiple threads within a Jakarta Container and therefore applicable to all applications not just full platform applications

 

2) Jakarta Concurrency is a very small api with no dependencies on other Jakarta apis therefore impact on complexity of the profile is very low given the enhancement in functionality

 

3) Much of the functionality of MicroProfile Context Propagation is planned to be incorporated into Jakarta Concurrency see https://groups.google.com/g/microprofile/c/884wrZdIyTs and so is applicable to core and web profile.

 

4) Jakarta Concurrency if in the core and web profiles, can be used by other apis to reimplement or replace some of their asynch processing e.g. a common Asynchronous capability providing a consistent and simplified experience to the Jakarta Platform.

 

5) If in the Core and Web Profiles Jakarta Concurrency can be used to provide much of the same functionality to CDI provided by Session Beans and Timer Beans e.g. @Lock, @Schedule, @MaxConcurrency based on the concurrency primitives.

 

6) Jakarta Concurrency can bring ability to use modern Java concurrency primitives like Fork/Join, Completable Futures to Jakarta EE simply and consistently. This would be of benefit to all profiles not just Full Platform.

 

For me this is a simple change to make to both Core and Web Profile to deliver foundational concurrency primitives to the whole Jakarta platform.

 

Thanks

 

Steve

 

 

 

-----Original Message-----

From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of Reza Rahman

Sent: 28 July 2021 18:53

To: JakartaEE Spec Project Leadership discussions <jakartaee-spec-project-leads@xxxxxxxxxxx>

Cc: jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx>

Subject: Re: [jakartaee-platform-dev] [jakartaee-spec-project-leads] Add Concurrency 3.0 to Web Profile?

 

Please do advise where and when you expand on the issue. I am generally supportive of this and will chime in after you.

 

Reza Rahman

Jakarta EE Ambassador, Author, Blogger, Speaker

 

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

 

> On Jul 28, 2021, at 1:29 PM, Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:

>

> --_000_PR3P194MB16840F9879BC222A313BFB9E91EA9PR3P194MB1684EURP_

> Content-Type: text/plain; charset="us-ascii"

> Content-Transfer-Encoding: quoted-printable

>

> I can pull it out into a separate platform issue if that is the

> recommended= approach. I think it has value as a foundational api on

> which other capabi= lities could be built. It is small, useful and

> doesn't bring along any othe= r baggage. I will expand on the advantages in the issue.

>

> Steve

>

>

>

> From: jakartaee-spec-project-leads

> <jakartaee-spec-project-leads-bounces@ec=

> lipse.org> On Behalf Of Kevin Sutter

> Sent: 28 July 2021 15:10

> To: jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx>;

> JakartaEE = Spec Project Leadership discussions

> <jakartaee-spec-project-leads@eclipse.o=

> rg>

> Subject: [jakartaee-spec-proj

_______________________________________________

jakartaee-platform-dev mailing list

jakartaee-platform-dev@xxxxxxxxxxx

To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

_______________________________________________

jakartaee-platform-dev mailing list

jakartaee-platform-dev@xxxxxxxxxxx

To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

 


Back to the top