Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cn4j-alliance] Thoughts on the CN4J purpose

Wearing my LJC hat I'll echo Arjan's comments here - we're hearing from developers that they want a single platform as an alternative choice to Spring (for those who have a Java EE background and are more comfortable with that technology set). Having both MicroProfile and Jakarta EE being touted as separate things when in reality you need both for a cloud-native first application or service doesn't make sense to them.

So although the proposed alliance is a step in the right direction, our users/developers are still wondering why they need to be apart at all now going forward.

Cheers,
Martijn


On Fri, 8 Jan 2021 at 17:36, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
Hi,

> This will be a lengthy discussion that we expect to involve members of both Jakarta and MicroProfile communities as well as their respective committees.

Thanks for starting this discussion.

IMHO, I think eventually it makes most sense for EE and MP to just fully merge. It made sense to have them separate when MP was at Eclipse and EE was still at the JCP and thereafter in transition.

Now that they're both firmly at Eclipse, and looking at the reality that very few implementations implement just MP, and even fewer users use just MP (from my, admittedly limited point of view that is), why not see this as the first step to eventually fully merge them?

The proposal among others mentions this:

"Jakarta should be the more stable platform with more support for existing Jakarta EE8 "

I feel this is a vendor decision to keep supporting Jakarta EE 8 for a long time. Jakarta itself has already released Jakarta EE 9, with a 9.1 in the works, and in parallel work for Jakarta EE 10 has started as well.

Jakarta EE is certainly not necessarily the slower or more legacy platform. We haven't established the cadence of Jakarta EE yet (we should soon), but a yearly release is the cadence I've most often heard being proposed.

Jakarta EE contains specs that MP bases on:
CDI, JSON P/B, REST

Jakarta EE also contains modern key specs next to ones MP is already using:
Bean Validation, Concurrency, Security, _expression_ Language, Persistence, Transactions, WebSocket.

Then there's a number of specs that MP is actually using, but they're not explicitly mentioned normally:
Interceptors (used via CDI), Dependency Injection (used via CDI), Annotations (used via JWT)

A number of the legacy specs have already been pruned from Jakarta, specifically: 
Deployment, Management, JAXR, JAX-RPC

Furthemore, for EE 10 plans are in place to create CDI alternatives for the Enterprise Beans things that are very useful, meaning Enterprise Beans itself could be deprecated before long.

Finally, EE contains a number of specs for Server Side Rendering (SSR) and their foundation:
Servlet, Faces, Pages, with new spec (not in the EE platform yet MVC).

So very long story short, for a ~20 year old platform, there's actually, IMHO, surprisingly little legacy still included.

Now the other way around, many of the MP specs were actually planned to be included in EE. This includes:
Config, Health, JWT and Fault Tolerance.


Kind regards,
Arjan Tijms











_______________________________________________
cn4j-alliance mailing list
cn4j-alliance@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cn4j-alliance

Back to the top