Re: [jakartaee-platform-dev] Jakarta EE next

[Ondro Mihályi <mihalyi@xxxxxxxxxxx>]

Hi,

From the top of my head, it would be nice to have Jakarta Config in EE 11 and some other specifications using it for configuration. In general, pulling some features from Microprofil that fit Jakarta EE would be useful, e.g. Rest client, which nicely fits into Jakarta REST already.

Adopting new features in Java 11 and 17 is also something that people expect these days. Mostly records, but I think support for some older constructs like the reactive Flow API are still missing.

And, in the CDI theme, I'm missing alternatives for some EJB constructs. Mostly in concurrency, like locking access to singletons, pooling, annotation-based timers, etc.

All the best,

Ondro Mihalyi

Director, Jakarta EE expert

OmniFish - Jakarta EE Consulting & Support | www.omnifish.ee

Omnifish OÜ, Narva mnt 5, 10117 Tallinn, Estonia | VAT: EE102487932

On Fri, Sep 9, 2022 at 2:04 PM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:

Hi,

One of the approaches I think is just asking for the ideas that the various committers and vendors have. That is *a* view of course, and things like surveys to gather more community and user input should probably be used as well.

One of the things I would like to look at for Jakarta EE Next is continuing the path of rebasing on CDI, and making CDI a clear core component model.

We've been on this path ever since CDI was introduced in EE 6. Particularly in EE 7 where @Transactional was introduced, EE 8 where Security was introduced that was fully based on CDI from the get go, and EE 10 where Faces pruned its native managed beans in favour of CDI (a plan that was announced all the way back in 2009).

There's still a bunch of open issues regarding this topic. For instance, in Jakarta Persistence, the EntityManager isn't directly injected via CDI. See https://github.com/jakartaee/persistence/issues/377

Also, for what should be a relatively modern specification, Jakarta Concurrency is still deeply rooted in JNDI, resource-refs, EJB,etc. We should really base this more on CDI. See https://github.com/jakartaee/concurrency/issues/229 and https://github.com/jakartaee/concurrency/issues/252

There's also a couple of things that are architecturally "wrong". Due to historical reasons, CDI itself knows about a couple of artefacts that it provides for injection, but those should be provided by the specifications that own these types. See e.g. Jakarta Transactions: https://www.eclipse.org/lists/jta-dev/msg00245.html

Kind regards,

Arjan Tijms

On Fri, Sep 9, 2022 at 1:25 PM Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:

Hi All,

 

The steering committee have tasked me, as a platform project committer,  to work in the Platform project, to get what  are our top objectives at the platform level for the next version of Jakarta EE.

 

I assume we can break this down into  Core, Full and Web. What do you think the best approach is to coming up with top project objectives for Jakarta EE next?

 

 

For context – this is part of a wider initiative to develop a narrative about the next release at the steering committee level which can be used to provide Early release positioning and messaging as well as setting some direction to individual api projects.

 

Thanks

 

Steve Millidge

_______________________________________________
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