[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakarta.ee-community] [jakartaee-platform-dev] Defining Jakarta EE 12 Scope in Program Plan
|
OK. Will follow up.
BTW, the public Jakarta EE marketing mailing list is copied.
Anyone can subscribe and post there any time. All feedback is
gold, especially if you find anything broken, outdated, or
incorrect.
The problem is that the Jakarta EE website needs to appeal to
higher level decision makers too - but point taken certainly.
Developers, architects, and technical managers are the primary
audience.
On 10/29/2024 11:18 PM, lenny--- via
jakartaee-platform-dev wrote:
Great discussion!
Some feedback I heard from developers...
When I send developers to https://jakarta.ee,
the #1 comment I get that it’s “marketing fluff” and they can’t
get to code examples,
step-by-step tutorials, videos, etc. They are indeed
buried.
Feedback #2:
Specification as a term, while valuable, is
confusing to developers. They don’t want “specification”, they
want something they can use.
These are code examples, plain and simple.
Modern way of doing code examples are through
snippets and demos, which integrate with Javadoc.
For example, in the FL Component Library, examples
are front-and-center, examples and demos are actually running
tests,
The library, coincidentally, fully uses CDI and
Jakarta EE :) :)
Hi..
I
really like the slides you shared, Reza.
It covers so many pain-points that I
actually wanted to bring up for
discussion, but I guess no need anymore :)
If
I may add a couple of suggestions, please.
- Let's split the
documentation into more focused
chunks. The current one is a big
tutorial with everything in it, and it
is overwhelming and confusing. Starter
Guides are good, but are not the
documentation/tutorial for developers.
- For website https://jakarta.ee/,
let's focus on users (software
developers) who uses the system,
rather than focusing on specs.
My target here it to reduce the
friction required to onboard someone
new to the platform
To elaborate:
- As a new developer to the
platform, my first entry point and
concern is not going to be the
specifications, but something like How to
Build a RESTful Web Service Using
Jakarta EE | Jakarta EE | The
Eclipse Foundation which is
currently, a bit buried deep in the
links.
- A clear "Get Started"
button at the center of the homepage
with a link to the starter guide
above would be far beneficial and
user friendly. e.g., similar to ReactNative (https://reactnative.dev/)
- I love the videos on
/learn page. Specifically this one:
https://www.youtube.com/watch?v=7mfVyPI360k&list=PLutlXcN4EAwDxs85DUnmbnWov3SusY9mG
, but it doesn't show how to run the
application.
- Increase the support for
Gradle?
For example:
- Dedicated tutorials for
Gradle similar to the Maven ones?
- Even better, updating the
existing tutorials to include both
options and ability for the user to
choose/switch between them.
e.g., something similar to how this
Spring Boot
Application :: Spring Boot
guide allows the developer to switch
between Java and Kotlin
Thank you.
Links in the message (2)
![]() |
|
Spring
Boot Application :: Spring Boot
|
![]() |
|
How
to Build a RESTful Web Service
Usin...
|
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
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
