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
Hi,

I'm also perceiving that the relationship between Jakarta EE and MicroProfile seems difficult to understand by certain developers. I just never understood why because it is not complex (personal opinion). In that regard, I never understood why developers find Spring Framework/Boot "not complex". I think there is some truth in the fact that Spring feels easier to just get going with compared to Jakarta EE / MicroProfile. Because you don't have to go through "the trouble" of looking for a runtime that runs your app? Is that it? Are we not just being lazy?

So now that we have this alliance, what is, or are exactly the problem(s) that we want to solve? Well, one example (maybe a solution in itself) that we already have is Quarkus. Here you can easily define the components you need, which are often based on Jakarta EE and MicroProfile specifications. This is a very good example of where it doesn't really matter from which platform the defined specification is maintained because a developer chooses a mix of ingredients for his app that happen to come from platform one, or platform two. This is much like how you set up Spring (boot) applications, and developers love it. So maybe this is the right approach to make the platforms currently in the alliance more elegant and accessible for developers?

Let's go back to the question of solving the "complex" relationship between Jakarta EE and MicroProfile. in the community, we have sent out polls on whether or not to merge the platforms without a conclusive answer from respondents AFAIK. Again, now we have this alliance, is this merge actually desired? It may, I don't have the answer right now, but I feel this might at least not the solution we are looking for. Thinking further on this, what happens if another working group joins the alliance because it has viable specifications to bring into the mix for solving certain problems that developers are looking for? I think therefore it is fine that we have several platforms and working groups providing specifications, and the answer lies more in how we make them accessible for end-users.

Edwin

On Tue, 12 Jan 2021 at 13:27, 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