Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec] [jakarta.ee-community] Defining Jakarta EE 12 Scope in Program Plan
Hey everyone, 

I'm just reviving this thread in hopes that someone can answer Reza's question below and perhaps we can move forward.
On Nov 11, 2024 at 10:31 PM -0500, Reza Rahman via jakarta.ee-community <jakarta.ee-community@xxxxxxxxxxx>, wrote:

The absolute least I can do now and going forward is give feedback with regards to competitiveness from a Spring and EJB migration perspective. My genuine struggle is where to provide such feedback in a proactive fashion.

Is it really all in the corresponding GitHub issues? On the Concurrency, etc mailing list? Somewhere else (please - don't tell me synchronous meetings I need to book time for during my working day :-().

In the JCP/Java EE days, the pattern was that the specification lead would start an API design proposal discussion on the mailing list. There would typically be pretty robust discussion and feedback on the mailing list. What's the analog these days?

On 11/11/2024 11:53 PM, Nathan Rauh via jakarta.ee-community wrote:

> The big question is, how did the idea that methods needed to be called came into the Concurrency API? We were all there, and nobody provided feedback to this I guess (I'm blaming myself too, as I missed it as well, and was very surprised to see this).

 

I was the one who added that.  Asynchronous was first added as an alternative to EJB Asynchronous, where you can call the method and optionally receive a Future handle that represents its eventual completion.   If we hadn’t offered an alternative to that pattern, then people would instead be asking the question of how to achieve that without EJBs.

 

Asynchronous was expanded to cover MicroProfile Fault Tolerance Asynchronous, and later to be able to run on a Schedule (Jakarta EE 11). We now have an issue on the backlog for designating an Asynchronous method to run automatically that would be a good candidate for Jakarta EE 12.

 

I don’t see this being about something gone wrong that needs explanation, only about having insufficient levels of staffing to achieve everything we wanted in a single release or even a couple of releases.  Every release since Jakarta EE opened up for new features, we have piled in features beyond was achievable into the Concurrency plan, with the idea that we would take as much as we can get done and defer the rest.  Every release we make more progress, adding in more features, which all represent a meaningful and useful subset of function.

 

 

From: Arjan Tijms <arjan.tijms@xxxxxxxxxxx>
Date: Monday, November 11, 2024 at 9:17 AM
To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Cc: Nathan Rauh <nathan.rauh@xxxxxxxxxx>
Subject: [EXTERNAL] Re: [jakarta.ee-community] Defining Jakarta EE 12 Scope in Program Plan

Hi, >Yes, it’s possible to rewrite EJBs with other constructs but the resulting code is much more verbose and easy to get wrong - timers in Concurrency require to call a method to trigger them, The big question is, how did the idea that methods

Hi,

 

>Yes, it’s possible to rewrite EJBs with other constructs but the resulting code is much more verbose and easy to get wrong - timers in Concurrency require to call a method to trigger them, 

 

The big question is, how did the idea that methods needed to be called came into the Concurrency API? We were all there, and nobody provided feedback to this I guess (I'm blaming myself too, as I missed it as well, and was very surprised to see this).

 

In EE 12 we probably should create a less verbose and more difficult to get wrong way of doing timers. Such a feature can build on the existing support in @Asynchronous that we have now I guess.

 

> running a method on startup is more verbose compared to @Startup on a singleton EJB, ApplicationScoped CDI beans are not thread safe unlike Singleton EJBs, @RolesAllowed only works on EJBs and not CDI beans, etc.

 

These are all things that had been on the list of things to do for EE 11.

 

E.g.

 

 

The biggest issue IMHO is not so much in lack of planning, ideas, or discussing, but in people who actually implement / do these things.

 

Kind regards,

Arjan Tijms

 

 

 

 

On Mon, 28 Oct 2024 at 23:25, Reza Rahman via jakarta.ee-community <jakarta.ee-community@xxxxxxxxxxx> wrote:

To be honest, I figured there was a high probability this debate would be inevitable. I kept it deliberately brief in the write up in the hopes that this is a subject pretty much all of the stakeholders are already well aligned on. Nonetheless, I will take this opportunity to more fully share my perspective on this. Perhaps it helps, perhaps it does not.

 

I have tried very hard to convince users and customers to use EJB for more than fifteen years now. The outcome for me is now firmly established. A small percentage (let's say 5-10%) get convinced and inevitably become ardent advocates. The rest immediately make the decision to choose Spring/Spring Boot instead. For this vast majority, EJB is well understood to be outdated, heavyweight, and bloated. As a result, the practical reality is that Jakarta EE as a whole consistently loses users and customers. If we continue to insist on clutching tightly to EJB, I have no doubt whatsoever that Jakarta EE adoption will never grow enough to sustain a critical mass of stakeholders that will be able to keep investing in it. Continuing the irreparably damaged EJB brand was a mistake in Java EE 5, 6, 7 and 8. It's a mistake I have personally paid a very high price for.

 

For me, the critical question in EE 12 is how much work can be done to convincingly tell the market they can finally use Jakarta EE without needing to use EJB. I understand the most ardent advocates of Jakarta EE are likely EJB fans (in fact count me in that crowd, I even wrote a book on EJB). I also understand for these users we need a graceful "off ramp" that will take some time and effort including early signals that we need to move on now, education on what the alternative approach is (i.e. the model that has successfully worked for Spring users/customers for years now), migration paths, guides, and tools.

 

From: jakarta.ee-community <jakarta.ee-community-bounces@xxxxxxxxxxx> on behalf of Ondro Mihályi via jakarta.ee-community <jakarta.ee-community@xxxxxxxxxxx>
Sent: Monday, October 28, 2024 12:55 PM
To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Cc: Ondro Mihályi <mihalyi@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [jakarta.ee-community] EJB -> CDI migration (was Re: Defining Jakarta EE 12 Scope in Program Plan)

 

I also think that until now, EJBs are not fully replacable with other Jakarta EE constructs. And thus we shouldn’t try to hide EJBs from developers learning Jakarta EE. In fact, teaching developers about EJBs simplifies things a lot. With just a single @Stateless or @Songleton annotation they get transactions automatically, can easily define timers, concurrency is handled (no state should be in stateless, singletons are syncrhonized). 

 

Yes, it’s possible to rewrite EJBs with other constructs but the resulting code is much more verbose and easy to get wrong - timers in Concurrency require to call a method to trigger them, running a method on startup is more verbose compared to @Startup on a singleton EJB, ApplicationScoped CDI beans are not thread safe unlike Singleton EJBs, @RolesAllowed only works on EJBs and not CDI beans, etc.

 

 Jakarta EE still needs improvements to fully replace EJB. And even then it would be good to have a single CDI annotation to enable all the features of EJB in a CDI bean. Until then, it’s better to teach EJBs and then explain how to use the new concepts in Jakarta EE to avoid EJBs for advanced developers.

 

Ondro

 

On Mon, 28 Oct 2024 at 15:01, Bernd Müller via jakarta.ee-community <jakarta.ee-community@xxxxxxxxxxx> wrote:

Hi all,

I completely agree with that. EJBs are not bad per se and should not be abandoned.
Everyone is free to use them or not.

Best regards,

Bernd


Am 28.10.24 um 14:54 schrieb Ralph Soika via jakarta.ee-community:
> Hello,
>
> I became aware of this discussion through the topic "EJB -> CDI migration" and would like to briefly
> share my thoughts about it.
> My fear here is to "ban" EJBs as something outdated, complicated and unnecessary. But is that right?
> I myself run with imixs.org <https://www.imixs.org> a very large Jakarta EE project. And my opinion
> is that you should always implement the DataAccessLayer as also complex ProcessingServices in a
> stateless EJB in order to make use of the transaction capability.
> I do know that you can also use CDI for data access. But is it the same?
>
> For example in my own project (a BPMN workflow engine) the DataAccess Service as also the Engine
> itself is implemented as a stateless EJB.
> A project that is using the library just need to inject the WorkflowEngine. The user does not have
> to think about transactions or EJBs at this moment. The app developer can now extend the engine
> behavior by implementing so called 'Plug-Ins' as simple CDI beans. Such a CDI bean is a kind of
> adapter class that can for example react on specific CDI Events in the processing life-cycle. And of
> course the developer can again inject the DataService form the Workflow Engine to create new data.
>
> The point is that if something goes totally wrong, the default transaction manager takes care about
> the rollback over all layers.
>
> And this all comes for free just because of using the stateless local EJB pattern. For the developer
> there is no need to think about EJBs at all.
>
> I may be wrong here, but I would always advise a developer to implement the data access layer via
> EJBs to keep the rest of the application as lean as possible.
> Therefore, in my opinion, EJBs play an important role. A tutorial should not hide its  concepts.
>
> Best regards
>
> Ralph
>
> On 28.10.24 14:21, Reza Rahman via jakarta.ee-community wrote:
>> I think the Tutorial refactoring work could easily be tagged “good first issue” and “help wanted”.
>> We have a shockingly low number of those across EE4J projects.
>> ----------------------------------------------------------------------------------------------------
>> *From:* Kito Mann <kito.mann@xxxxxxxxxxx>
>> *Sent:* Sunday, October 27, 2024 11:50 PM
>> *To:* jakarta.ee-spec@xxxxxxxxxxx <jakarta.ee-spec@xxxxxxxxxxx>; Jakarta EE community discussions
>> <jakarta.ee-community@xxxxxxxxxxx>; jakarta.ee-marketing@xxxxxxxxxxx <jakarta.ee-
>> marketing@xxxxxxxxxxx>; Reza Rahman <reza_rahman@xxxxxxxx>
>> *Cc:* Jakarta EE Ambassadors <jakartaee-ambassadors@xxxxxxxxxxxxxxxx>; juneau001@xxxxxxxxx
>> <juneau001@xxxxxxxxx>; Kito Mann <kito.mann@xxxxxxxxxx>
>> *Subject:* Re: EJB -> CDI migration (was Re: Defining Jakarta EE 12 Scope in Program Plan)
>> I love all three of these ideas:
>>
>>  1. EJB -> CDI Migration Guide
>>  2. New EJB -> CDI Migration talk
>>  3. Updating the Jakarta EE Tutorial to remove EJB when possible
>>
>> (3) is non-trivial since a lot of work needs to be done upgrading/rewriting the examples in
>> general, but that doesn’t mean I can’t at least break that work down into the issue tracker. Also,
>> the intro (which I rewrote) specifically does not mention EJB.
>>
>> I’d like to add another: Writing an OpenRewrite  for migrating from EJB->CDI.
>>
>> ___
>>
>> Kito D. Mann <https://kitomann.com> | @kito99@mastodon.social <https://mastodon.social/@kito99>|
>> LinkedIn <https://www.linkedin.com/in/kitomann/>
>> Java Champion | Google Developer Expert Alumni
>> Expert consulting and training: Cloud architecture and modernization, Java/Jakarta EE, Web
>> Components, Angular, Mobile Web
>> Virtua, Inc. | virtua.tech <http://virtua.tech>
>> +1 203-998-0403
>>
>> * Enterprise development, front and back. Listen to Stackd Podcast <http://stackdpodcast.com/>.
>> * Speak at conferences? Check out SpeakerTrax <https://speakertrax.com>.
>> On Oct 27, 2024 at 2:46 PM -0400, Reza Rahman <reza_rahman@xxxxxxxx>, wrote:
>>
>>     I am moving comments on my Jakarta EE 12 Google Doc
>>     (https://docs.google.com/document/d/1U2qEqF9K969t5b3YuX4cwex5LJPvF3bt1w27cdKNpDM/edit?usp=sharing)
>>     to Jakarta EE mailing lists when possible. The problem with Google Docs
>>     comments is that they do not scale very well, aren't very readable on
>>     smaller devices, and do not archive well. I will do so one email per
>>     comment. The person commenting is copied.
>>
>>     Context: Why does replacing EJB matter?
>>
>>     Josh Juneau (Community): Are there any comprehensive tutorials on how to
>>     utilize CDI rather than EJB for querying entities? It seems like these
>>     tutorials need to be made front and center in an effort to help steer
>>     people to CDI and to show that EJB is no longer needed in many cases.
>>
>>     Reza Rahman (Microsoft): Good point. As of Jakarta EE 11, it is indeed
>>     possible to just use CDI now for basic CRUD in a transactional and
>>     thread safe manner with Jakarta Persistence. The same for EJB
>>     @Asynchronous and @Schedule. At the bare minimum, this is worthy of an
>>     Eclipse Foundation newsletter article and/or JakartaOne talk. The
>>     material could cover where EJB is not needed any more and where it is
>>     still needed. The title could be something attention grabbing like -
>>     "EJB is Dead, Long-Live CDI and Jakarta EE". We could also ensure a
>>     revised Jakarta EE 11 Tutorial can avoid using EJB when possible. Maybe
>>     Kito could comment on this? Additionally, the Marketing Committee has
>>     been sponsoring some guides. Could we consider already starting an EJB
>>     migration guide?
>>
>>     On 10/22/2024 5:30 AM, Reza Rahman 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
>>
>>
>> Reza Rahman
>>
>> Principal Program Manager
>>
>> Java on Azure at Microsoft
>>
>> reza.rahman@xxxxxxxxxxxxx
>>
>> +1 717 329 8149
>>
>>
>> _______________________________________________
>> jakarta.ee-community mailing list
>> jakarta.ee-community@xxxxxxxxxxx
>> To unsubscribe from this list, visithttps://www.eclipse.org/mailman/listinfo/jakarta.ee-community
> --
>
> *Imixs Software Solutions GmbH*
> *Web:* www.imixs.com <http://www.imixs.com> *Phone:* +49 (0)89-452136 16
> *Timezone:* Europe/Berlin - CET/CEST
> *Office:* Frei-Otto-Str. 4, 80797 München
> Registergericht: Amtsgericht München, HRB 136045
> Geschäftsführer: Gaby Heinle u. Ralph Soika
>
> *Imixs* is an open source company, read more: www.imixs.org <http://www.imixs.org>
>
>
> _______________________________________________
> jakarta.ee-community mailing list
> jakarta.ee-community@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community


--
Prof. Dr. Bernd Müller

Ostfalia
Hochschule für angewandte Wissenschaften
- Hochschule Braunschweig/Wolfenbüttel -
Fakultät Informatik
Salzdahlumer Straße 46/48
38302 Wolfenbüttel

Tel  +49 5331 939 31160
Fax  +49 5331 939 31004
Web  www.ostfalia.de / www.pdbm.de

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community


_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

Back to the top