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
At this juncture, I must say I entirely agree with Martijn and Arjan in spirit. However, I am currently still trying to solicit opinions as broadly and genuinely as I can.

It is evident there are many practical nuances with regards to MicroProfile and people that feel strongly about their respective positions.

Ultimately I would like to see this CN4J Alliance make a significant difference and be able to achieve tangible progress. I don't think the status quo of various key stakeholders having widely varying positions that seem rather distant from each other and sometimes end users is tenable or good for anyone. Achieving progress will inevitably require more hard work, flexibility, collaboration and incremental progress.

I will take the time to provide a more detailed and better vetted perspective in the next few days and weeks. This is it for me for now.

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.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone


-------- Original message --------
From: Martijn Verburg <martijnverburg@xxxxxxxxx>
Date: 1/12/21 7:27 AM (GMT-05:00)
To: Discussions on formation of a CN4J Alliance with the MicroProfile Working Group <cn4j-alliance@xxxxxxxxxxx>
Subject: 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