Re: [jakartaee-platform-dev] Defining Jakarta EE 12 Scope in Program Pla

["werner.keil@xxxxxxx" <werner.keil@xxxxxxx>]

Angelo/All,

Thanks for your detailed message.

As for the comparison with car engines, it's not like European vendors don't have electric cars for some time, they are just not consequent enough and still want multiple eggs in their basket, despite some of them having become old and foul.

Many of them depend on lobbyists from the fossil-fuel industry, something Trump in the US also does, and it will be interesting to see, how he'll handle their interests and needs compared to Tesla and Musk.

So it's a bit like vendors trying to maintain both EJB and CDI (which is btw. also a Diesel injection technology at Mercedes ;-) for a very long time.

I compared the async behavior of CDI and EJB in a video tutorial about Java EE High Performance a little while ago on the brink of Jakarta EE 8. 

Back then there were still several points, where EJB Async was superior, maybe CDI closed the gap in a few of them.

Kind Regards,

Werner

---

From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> on behalf of Angelo Rubini via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx>
Sent: Friday, November 8, 2024 9:33 AM
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: Angelo Rubini <angelorubini@xxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Defining Jakarta EE 12 Scope in Program Plan

 

Hi everyone, 

Making a comparison with the automotive world: 
"Let's not make the mistake like Europe which deprecated/removed the production of petrol/diesel powered engines,
 without building/providing a valid alternative immediately..."

I like Ondro's, Bernd Müller, Ralph Soika,Ondro Mihályi comment EJB is not a bad spec. 
Whatever the new spec like @Service may be, It will be important to maintain ejb features such as: 
remote calls between ejbs (with efficient binary protocols), keeping transactions DISTRIBUTED, between remote calls between ejbs, 
security context distribution. 

Perhaps it would be desirable to retain the functionality that if an ejb is calling a method of another ejb the AS,
 understands that if the two ejbs are on the same instance of jvm the call will be local rather than remote. 

By comparison, spring boot or other frameworks like helidon and quarkus do not have these features, 
for example in spring boot the giant Alibaba/Alipay have written a framework for rpc Dubbo (https://dubbo.apache.org/en/) 
for satisfy remote calls with (efficient) binary protocols between services and also wrote the seata(https://seata.apache.org/) framework for 
distributed transactions. 

This shows that in complex/enterprise contexts rmi/rcp calls between components(like EJB @Remote Stateless/new @Service) 
and distributed transactions between them ARE IMPORTANT. 

Lastly, but still important, Google has written a new framework Service weaver  (https://serviceweaver.dev/blog/vision.html) 
which practically refers to the EJB component model of the first J2EE specifications. 

Finally I say, ok to change the name of a specification, but let's not lose these features which, as we see in complex and enterprise contexts, are fundamental. 
Furthermore, it would be important that in future talks on Jakarta ee we start talking about distributed transactions 
between distributed applications again and show how Jakarta ee applications solve these problems. 

What do you think?
Greetings everyone

Angelo Rubini

---

Da: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> per conto di Ryan Cuprak via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx>
Inviato: venerdì 8 novembre 2024 00:15
A: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: Ryan Cuprak <rcuprak@xxxxxxx>; JakartaEE Spec Project Leadership discussions <jakartaee-spec-project-leads@xxxxxxxxxxx>; jakarta.ee-spec@xxxxxxxxxxx <jakarta.ee-spec@xxxxxxxxxxx>; jakarta.ee-wg@xxxxxxxxxxx <jakarta.ee-wg@xxxxxxxxxxx>
Oggetto: Re: [jakartaee-platform-dev] Defining Jakarta EE 12 Scope in Program Plan

 

I like the document.

I agree on the deprecation and removal of old technologies. However, EE is know for stability and we don’t want too aggressive.

I propose a tool that will scan an EE application and will give a health report. If people share these health reports, we can get a sense of the impact of a deprecation and removal.

There has to be an incentive for removal as we don’t want to increase Jakarta EE developmental costs unnecessarily. Java EE / Jakarta EE got a black eye for the namespace migration. For large organizations it was undoubtedly expensive.

 What does removing EJB get us? CDI doesn’t fully replace it yet.

-Ryan

> On Oct 22, 2024, at 5:30 AM, Reza Rahman via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
>
> Hi folks,
>
> I would like to see if we can define clear, compelling, and specific
> scope for Jakarta EE 12 as part of the Steering Committee Program Plan:
> https://docs.google.com/presentation/d/1xUNDHMP_qTHH1wA3m0yCmWVf_sHp41Qd7Opq3FhgINs/edit?usp=sharing.
> I believe this is of critical importance at this juncture. If I did not
> think so, I would not bother trying. I have detailed all the rationale
> here:
> https://docs.google.com/document/d/1U2qEqF9K969t5b3YuX4cwex5LJPvF3bt1w27cdKNpDM/edit?usp=sharing.
> For those that recall, something very similar was done for Jakarta EE
> 11, so this isn't exactly without precedent.
>
> I would like to see if this can be done in the following couple of
> weeks, when the Program Plan is due.
>
> Thanks,
>
> Reza
>
> _______________________________________________
> 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