[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-platform-dev] [jakarta.ee-community] Defining Jakarta EE 12 Scope in Program Plan
|
Nathan, Ondro, and others,
Can someone kindly point me in the right direction to better
understand the @Asynchronous and @Schedule annotations in
Concurrency? Is it the specification PDF that I should look at?
It is 100% possible these APIs might need some improvements to be
more compelling to EJB and Spring Boot users. Unless someone else
gets to it first (awesome!), I am happy to enter a few
issues/update issues.
Thanks,
Reza
On 10/29/2024 9:47 AM, Nathan Rauh via
jakartaee-platform-dev wrote:
Ondro,
I did not
see any existing issues against the Concurrency
specification covering the idea you brought up for an
Asynchronous method to be automatically scheduled upon
startup. I agree it seems useful, so I opened a new issue in Concurrency for
it.
Hi all, This is
a great starting point for discussions around the
release. Please note that some of the items have
been discussed and decided by the Platform Project
some time ago, so don't waste time discussing these
items in other forums.
Hi all,
This is a great starting point
for discussions around the release.
Please note that some of the
items have been discussed and decided by the
Platform Project some time ago, so don't waste time
discussing these items in other forums. Here are
some of them (note that there may be more):
- Release Timeframe: H1, 2026
- Java SE: We continue the
strategy of supporting the previous and current
"LTS" of Java SE. For this release that would mean
to compile to
21, and pass TCK on 21 and 25.
- CDI alignment: The work started
in Jakarta EE 10 an continued in Jakarta EE 11 will
be carried forward in Jakarta EE 12
Refer to these pages for details:
I agree with you, Reza. My
point was that alternatives to EJB are often more
cumbersome than just using EJBs. The sad reality
is that some things now work only with CDI, some
work only in EJBs, and things work in both but
often are easier with EJBs.
Examples of things that still
require EJBs:
- a single annotation that
turns on transactions, synchronous access,
dependency injection, bean pooling - with CDI you
need a separate annotation for each
- security with @RolesAllowed,
etc - this simply doesn’t work in CDI in general,
only some implementations support it
Examples of things that are
much more complicated without EJBs
- cron-like timers - with EJB
it’s a method with a single annotation and cron
_expression_. Without EJBs, concurrency in EE 11
will allow something similar but still require to
execute the method at startup, which is again much
more code without EJBs
- run a method on startup -
just a single annotation on EJB and a
postConstruct method, with CDI it’s an observer
with a long complicated set of annotations
I’d like to address these
things in EE 12. Thrn I would be comfortable with
suggesting people to avoid EJBs completely. Then
it would be really easy to start with Jakarta EE
even for newcomers and be productive for advanced
decelopers.
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.
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
>>
>>
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
--
Ivar
Grimstad
Jakarta
EE Developer Advocate |
Eclipse
Foundation
Eclipse
Foundation
- Community. Code. Collaboration.
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
