| Re: [jakarta.ee-spec] Defining Jakarta EE 12 Scope in Program Plan |
Personally I think you could just use JCache for this sort of
thing these days. That said, if this is deemed important enough,
one could introduce @Pooled or @PoolScoped. Concurrency might be
the best place for it.
On Oct 29, 2024, at 11:36 AM, Reza Rahman via jakarta.ee-community <jakarta.ee-community@xxxxxxxxxxx> wrote:
Instance pooling is another outdated artifact of the past. It was more necessary in the early days when the JVM was not efficient at garbage collection. These days it's simply overkill.
It's absolutely correct that the original motivation for instance pooling is no longer relevant. Reza knows, but for those that weren't around in the early days the motivation was that creating and destroying java objects was expensive. This was fixed at the JVM level around Java 1.2.
Where I've seen this used in recent years is just pooling in general for any expensive resource. They create a stateless bean that holds and encapsulates one "instance" of the expensive resource. The EJB spec has the whole check-in / check-out mechanism built in, then they rely on the pooling config of the container to set the min and max number of instances.
One of the most compelling I've seen is one of the global leaders in GIS data use it to manage map data in memory. They had a DCOM object associated with a specific region and each region represented a few hundred MB of memory, so they had to be managed very very carefully.
-David
_______________________________________________On 10/29/2024 11:42 AM, Bauke Scholtz via jakarta.ee-community wrote:
Hi,
> I did not understand why EJB Containers have this pooling mechanism.
EJB instances are basically synchronized. This is unnecessary for stateless beans so they introduced pooling. CDI instances are basically unsynchronized. So pooling is unnecessary.
Cheers, B
On Tue, Oct 29, 2024 at 11:04 AM Ralph Soika <ralph.soika@xxxxxxxxx> wrote:
Hi,
ok, I trust you ;-)
But then, I did not understand why EJB Containers have this pooling mechanism. That sounds like a CDI container is superior to an EJB container ?
Best regards
Ralph
On 29.10.24 15:41, Bauke Scholtz wrote:
Hi,
> But the CDI application can only serve the requests from one single CDI Bean.
The class is stateless and @ApplicationScoped bean methods are not locked/synchronized/queued unlike @Singleton. So instance reuse has no harm.
Cheers, B
On Tue, Oct 29, 2024 at 10:30 AM Ralph Soika via jakarta.ee-community <jakarta.ee-community@xxxxxxxxxxx> wrote:
_______________________________________________I took a look on the tutorial form Bauke and I wonder if I understand your recommendations correctly?
The first example shows a stateless EJB with the @Stateless annotation. In the CDI variant you use the @ApplicationScoped annotation. I have seen this often in other code examples.
But I wonder if this annotation is a good or equivalent solution? From my understanding the @ApplicationScoped annotation is a singleton pattern.
But a stateless EJB uses the Container pool mechanism. Which means the EJB application can use many beans in parallel. But the CDI application can only serve the requests from one single CDI Bean.
Or am I totally wrong here?
===
Ralph
On 29.10.24 13:35, Bauke Scholtz via jakarta.ee-community wrote:
Hi,
> 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.
Cheers, B
On Tue, Oct 29, 2024 at 6:05 AM Luqman Saeed via jakarta.ee-community <jakarta.ee-community@xxxxxxxxxxx> wrote:
I agree. I think we need to clarify the problem with EJB. Is it technical, as in there's a lot of baggage/fat that simply cannot be shed without completely killing the tech? Especially from an implementation perspective?Or is it more a problem of perception, where a whole generation of developers have grown up hearing nothing but horror stories from the days of entity beans and thus, would want to steer clear of EJB and consequently, the platform itself?
Personally I lean towards "spring cleaning" the internals of EJBs if it's a problem of the former and leaving the technology alone.Why? Because it just works. A single annotation does a lot of heavy lifting on my behalf. And that is cool. It's also easy to teach newcomers.
From a business perspective, I'd ask, which would add more weight to portraying the platform as modernising?
- A test spec/attempt to standardize consuming AI on the platform?
- Or killing EJBs?
If the goal is to portray the platform as alive and modernising, I think nothing is more a testament than an incubator spec that taps into arguably the most hyped tech of our time?We may have different views of the whole AI stuff, but if Spring already has Spring AI, Quarkus has native integration with LangChaing4J, where's Jakarta?
So though EJB may be a polarising tech depending on who you speak with, I think if the goal of EE 12 is to show that it's still a technology that is evolving with the times, then our target lies elsewhere.Not necessarily EJB. At least not this time.
_______________________________________________On Mon, 28 Oct 2024 at 16:55, Ondro Mihályi via jakarta.ee-community <jakarta.ee-community@xxxxxxxxxxx> wrote:
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--
Imixs Software Solutions GmbH
Web: 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 SoikaImixs is an open source company, read more: 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
--
Imixs Software Solutions GmbH
Web: 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 SoikaImixs is an open source company, read more: 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
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community