Scott (Red Hat): This is not really a valid comparison in my
view. The OpenJDK project still is effectively a benevolent
dictator model. I also don't believe the rapid cadence has been
universally accepted.
Reza (Microsoft): I suspect we may need to agree to disagree on
this one, but at least I can try to explain a bit more where we
are coming from.
What we observe from our customers is that they indeed adopt Java
SE versions very slowly on Azure (a majority is still on Java SE 8
and Java SE 11). Nonetheless, when it comes to evaluation-like
activities they demand the latest Java SE version and say they are
very excited about the newest features such as Records and Virtual
Threads (and soon CRaC, native compilation, etc). This is the
reason why on our services like Azure App Service we try very hard
to stay up-to-date. We look at Jakarta EE the same way. The latest
Jakarta EE Developer Survey appears to corroborate our view,
including on faster cadence, Java SE version support, and adopting
Java SE features sooner:
https://blogs.eclipse.org/post/tatjana-obradovic/rising-momentum-enterprise-java-insights-2024-jakarta-ee-developer-survey.
We value vendor neutrality no doubt. It's one of the key reasons
we are here. The problem is that our Java customers say what they
actually care about far more is time-to-market. The vast majority
of our customers Jakarta EE continues to lose to Spring Boot are
particularly vocal on this point. Their eyes basically roll over
the moment we try to talk about why vendor neutrality is something
they should care more about.
This should logically bring us to another key consideration -
does being multi-vendor have to mean being slower and having less
to show for in releases? I have to say the Economist in me that
has an active interest in Organizational Theory really does not
think so. Effective alliances should be able to consistently
out-compete most unilateral approaches. The fundamental reason for
this typically is that good alliances can bring to bear greater
collective resources, economies of scale, and strategic depth.
They key is whether an alliance has a critical core mass of
players that have fundamental alignment and an ability to
collaborate effectively. I have always hoped that to be true for
Jakarta EE and hope that it can materialize in a more compelling
Jakarta EE 12 release.
On 10/27/2024 3:42 PM, Reza Rahman via
jakarta.ee-spec wrote:
Apologies, Scott - I was actually just in the process of moving
them. Thanks for just getting it done, saves me a bit of time.
Let me try and respond one comment at a time to try to avoid
overlong emails.
Scott (Red Hat): The deprecation model in Jakarta EE is still
too conservative. As soon as a feature is deprecated all related
TCK should be archived and no longer required for compatibility.
Vendors are free to support the feature and run the archived
tests, but they are no longer a requirement for compatibility.
Reza (Microsoft): Microsoft very much supports this view. I am
not sure where Working Group current consensus is on this, but
we would be happy to vote +1 on this where possible.
On 10/27/2024 3:17 PM, Scott Stark
wrote:
Moving some comments I had made on the doc that I
don't see here:
Regarding the Why
is a timely, up-front deadline important? section,
and the statement "but
Java SE has done so in a far more effective way,"
This
is not really a valid comparison in my view. The OpenJDK
project still is effectively a benevolent dictator model.
I also don't believe the rapid cadence has been
universally accepted.
Regarding
the Why
does aggressive deprecation matter? section, The
deprecation model in Jakarta EE is still too conservative.
As soon as a feature is deprecated all related TCK should
be archived and no longer required for compatibility.
Vendors are free to support the feature and run the
archived tests, but they are no longer a requirement for
compatibility.
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
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
