Fwd: [jakarta.ee-spec] Defining Jakarta EE 12 Scope in Program Plan

[Reza Rahman]

Dear fellow Ambassadors,

I am asking for your help with this. You should chime in to the mailing lists below. Better yet, if you can somehow help make some of the work happen, that is simply outstanding.

Thanks,

Reza

-------- Forwarded Message --------

Subject:	[jakarta.ee-spec] Defining Jakarta EE 12 Scope in Program Plan
Date:	Tue, 22 Oct 2024 11:30:50 +0200
From:	Reza Rahman via jakarta.ee-spec <jakarta...@eclipse.org>
Reply-To:	Jakarta specification discussions <jakarta...@eclipse.org>
To:	jakarta...@eclipse.org, jakartaee-platform developer discussions <jakartaee-p...@eclipse.org>
CC:	Reza Rahman <reza_...@mail.com>, jakart...@eclipse.org, JakartaEE Spec Project Leadership discussions <jakartaee-spec...@eclipse.org>

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-spec mailing list
jakarta...@eclipse.org
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec

[Reza Rahman]

BTW I want to see how far I can push this forward by October 31, roughly when the Steering Committee Program Plan needs to be finalized. If you can at least post something on those mailing lists by then, I believe it will make some difference.

 

---

From: Reza Rahman <reza_...@mail.com>
Sent: Tuesday, October 22, 2024 11:38 AM
To: Jakarta EE Ambassadors <jakartaee-...@googlegroups.com>
Subject: Fwd: [jakarta.ee-spec] Defining Jakarta EE 12 Scope in Program Plan

 

Reza Rahman

Principal Program Manager

Java on Azure at Microsoft

reza....@microsoft.com

+1 717 329 8149

[Reza Rahman]

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?

[Scott Stark]

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.

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee...@eclipse.org
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community

[Scott Stark]

Regarding a comment in the doc about configuration and moving MP config into Jakarta, the easiest thing to do given the current state of Jakarta Config, which essentially boils down to:

public interface Config {
    /**
     * Loads an object of the supplied {@code type} from the current {@link Config} <em>configuration path</em>.
     *
     * @param <T> the type of object to load
     * @param type the type of object to load; must not be {@code null}
     * @return the loaded object; never {@code null}
     * @exception NoSuchElementException if the requested object is not found.
     * @exception IllegalArgumentException if the supplied {@code type} was invalid for any reason
     * @exception NullPointerException if the supplied {@code type} was {@code null}
     */
    <T> T load(Class<T> type);

}

and some annotation for customizing the binding fields on a configuration POJO, Jakarta Config could just be released as is with a very simple POJO configuration object view with the details left to the implementation. Vendors supporting MP config would leverage that for the serialized forms, type conversion, etc. Specs would need to define their configuration POJOs. MP config could be the de facto portable format.

On Sun, Oct 27, 2024 at 12:46 PM Reza Rahman via jakarta.ee-community <jakarta.ee...@eclipse.org> wrote:

[Kito Mann]

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 | @kit...@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.

[werne...@gmail.com]

MP Config was more or less a blueprint for Jakarta Config. Then the slate was wiped clean, so should that be reverted again?

I did not follow the activity in the Config spec recently, because I focussed more on Data on its way into Jakarta EE 11.

With vendor exchange and compromises here and there it got finished.

I assume, the old MP design was not abandoned for nothing, maybe some aspects of it are valuable, so everyone involved should work together the same way as we saw with Data, then it should hopefully be ready for Jakarta EE 12.

Werner

[Reza Rahman]

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...@virtua.tech>
Sent: Sunday, October 27, 2024 11:50 PM
To: jakarta...@eclipse.org <jakarta...@eclipse.org>; Jakarta EE community discussions <jakarta.ee...@eclipse.org>; jakarta.ee...@eclipse.org <jakarta.ee...@eclipse.org>; Reza Rahman <reza_...@mail.com>
Cc: Jakarta EE Ambassadors <jakartaee-...@googlegroups.com>; june...@gmail.com <june...@gmail.com>; Kito Mann <kito...@virtua.com>
Subject: Re: EJB -> CDI migration (was Re: Defining Jakarta EE 12 Scope in Program Plan)

 

[Kito Mann]

Indeed. I've been doing that as much as possible, and it definitely helps, especially with low hanging fruit.

___

Kito D. Mann | @kit...@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.