[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakarta.ee-community] Defining Jakarta EE 12 Scope in Program Plan
|
I agree with the points from Reza and I think we all know well
these boring discussions about Spring vs. JakartaEE. As a Jakarta
EE developer you develop against an API, as a Spring developer you
develop against a big mud of libraries. For me, this is a question
about one's own claim to clean architecture. We should not
continue this discussion here.
For me, the question that I can't answer myself is, what do the
EJB container teams actually say about all this? Are they
frustrated because they see that all their functionality can be
achieved just as well or even better with CDI containers?
Let's sort out the Statefull and Remote EJBs here. The question
for me is, is a Stateless EJB with its integrated transactional
behavior really replaceable by a CDI bean?
And if it's just the 3 letters of name, then let us just rename
the whole thing to "Caribbean Beans".
===
Ralph
On 28.10.24 23:25, Reza Rahman via
jakarta.ee-community 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.
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
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
--
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 Soika
Imixs is an open source company,
read more: www.imixs.org
