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

One fundamental issue for Red Hat and its existing Java EE customers is that a strong statement towards backwards compatibility and portability existed in Java EE. It is not even clear at this point whether they are willing to accept that Jakarta EE 9 namespace change. Currently there is support to transform a Java EE based application into a Jakarta one, but there are no requirements on this front. Adding that is the purpose of the enterprise/xyz named profile.

The other issue on the Quarkus front is that there is no agreement on what it means to be compatible with a given MicroProfile platform. The lack of a clear transitive dependency path from MP to a Jakarta packaging of APIs with a TCK is the problem here. A new Jakarta core platform would address this.

Another major difference between MicroProfile and Jakarta are the differing working group charters/procedures and vastly different fee structures. 

The other direction we could take is to essentially ignore the Java EE heritage and look at Jakarta EE as a complete reboot that is only offering specifications with the same perspective as Java EE. 


On Tue, Jan 12, 2021 at 6:27 AM Martijn Verburg <martijnverburg@xxxxxxxxx> wrote:
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
_______________________________________________
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