| I may be having issues with the semantics here: what do we mean by the word “deprecated”?
- if we mean “officially removed from the Spec” then I agree, all related TCK should be removed and no longer be required for compatibility
- if we mean “marked for removal” then it is still part of the Spec and therefore TCK should still be there and it should still be required for compatibility. When we rewrote the versioning scheme we did say that features need to be marked for removal for at least one full major version; if vendors don’t need to pass the TCK for that spec in order to be certified then effectively we’ve removed it before its time
— Abraham Marin-Perez
🖥️ https://www.cosotateam.com/ 💼 https://www.linkedin.com/in/abraham-marin-perez/ 🐦 https://twitter.com/AbrahamMarin
On Oct 27, 2024, at 12:42 PM, Reza Rahman via jakarta.ee-spec <jakarta.ee-spec@xxxxxxxxxxx> 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
|
