[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakarta.ee-spec] Defining Jakarta EE 12 Scope in Program Plan
|
No worries whatsoever. Even the domain experts have trouble
getting this stuff.
Part of the exercise here is educating why this isn't just the
right thing to do in terms of marketability/adoption, but also
even from an existing user standpoint. This way is far more
modern, flexible, and powerful, without necessarily any real loss.
Doubtless there is work to be done in EE 12 to actually make it
happen.
On 10/29/2024 5:38 PM, Ralph Soika
wrote:
Reza and Bauke: Yes, I have now taken a closer look at the
concepts and understand it now much better. I fully agree now
with this and I am sorry to have stopped the ongoing discussion.
But at least I learned today a lot ;-)
On 29.10.24 21:00, Reza Rahman wrote:
Ralph: The question for me is, is a Stateless EJB with its
integrated transactional behavior really replaceable by a CDI
bean.
Reza: This is 100% possible using a much better named,
modernized, built-in CDI Stereotype that vendors can even add
more functionality to. It's in the write-up and here is the
basic blueprint: https://speakerdeck.com/reza_rahman/contributors-guide-to-the-jakarta-ee-12-galaxy?slide=26.
In my opinion, the approach the Spring developers tend to take
is actually the better one: they explicitly opt in to the
exact component life-cycle and services they need.
Alternatively, one could define their own CDI Stereotype with
the exact things that your application needs - even giving it
a name you like best. As Bauke has already pointed out, this
is largely possible even in Jakarta EE 11.
On 10/29/2024 3:33 AM, Ralph Soika
via jakarta.ee-community wrote:
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
_______________________________________________
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
