[
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
|
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.
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
>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.
The biggest issue IMHO is not so
much in lack of planning, ideas, or discussing, but
in people who actually implement / do these things.
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
>>
>>
>> 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
