| Re: [jakartaee-platform-dev] [jakarta.ee-community] Defining Jakarta EE 12 Scope in Program Plan |
The difference with the OpenJDK may be that Jakarta EE vendors
rarely seem to actually remove deprecated/pruned features. It's
largely symbolic and there may not be an actual practical
difference between deprecation and pruning anyway.
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.
It seems to me that everything should be required, even if it's deprecated, until it is pruned. Not supporting a deprecated feature would be quite confusing, since the Java platform has always supported deprecated features until they are pruned.
___
Kito D. Mann | @kito99@mastodon.social | LinkedIn
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
+1 203-998-0403
* Enterprise development, front and back. Listen to Stackd Podcast.
* Speak at conferences? Check out SpeakerTrax.On Oct 27, 2024 at 3:17 PM -0400, Scott Stark via jakarta.ee-community <jakarta.ee-community@xxxxxxxxxxx>, 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.
_______________________________________________On Sun, Oct 27, 2024 at 12:46 PM Reza Rahman via jakarta.ee-community <jakarta.ee-community@xxxxxxxxxxx> 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
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