Re: [rest-dev] Jakarta Rest 3.2?

[Jim Krueger <jckofbyron@xxxxxxxxx>]

You make several valid points here Markus and I agree to a point:

For examples, are there changes in master already that are not allowed in 3.2 because they break backwards compatibility? 

Yes, while most changes have gone into the release-4.0 branch I assume there may be some in master.   We will need to look at all PRs to ensure they belong in release-3.2.   

Will there be anything interesting in 3.2 at all so is it worth the time? And what do we actually win,

If EE-11 sticks to their current schedule there may not be time for much more than the formal deprecation, and even that will be a challenge..   But since the possibly CI would need to include an alternative implementation, along with the appropriate spec and API changes, it is a significant step toward the goal for Jakarta Rest-4.0 to entirely remove @Context injection.   Arjan’s point that this has taken longer than it should have is valid, but I still think that we could benefit from deprecation first to ease the transition and allow for the alternative implementation and users to discover issues/potential shortcomings prior to the eventual removal of @Context in 4.0.

I do not see that those people that have no time for 4.0 *now* will have more time for 4.0 *tomorrow*. 

Very true.  However I know that work is underway that could potentially provide a CI with an alternative implementation by the end of February, and I’m hoping to have time to work on spec and TCK changes for this by then as well.   Hopefully others will have time to contribute, or at least help to review changes and contribute to the discussion of potential issues.

Bottom line (IMO): If 3.2 makes EE11 it is certainly beneficial to the community, even if all we do is formally deprecate @Context.   In the worst case 3.2 is dropped out of EE11 and we go with 4.0 in EE12, but we have the benefit of the progress made to solidify some of the open questions/concerns about @Context removal.   In the best case scenario, the schedule for EE11 is impacted by factors outside of Jakarta Rest, allowing us to add more content to 3.2.  Certainly we cannot count on that, but you never know.

Am I being overly optimistic?  Quite possibly.

On Jan 13, 2024, at 2:40 AM, Markus Karg <markus@xxxxxxxxxxxxxxx> wrote:

This sounds like a good idea, but it opens questions too: For examples, are there changes in master already that are not allowed in 3.2 because they break backwards compatibility? Who will invest the work to remove them, will those changes be in-time for EE 11? Will there be anything interesting in 3.2 at all so is it worth the time? And what do we actually win, as I do not see that those people that have no time for 4.0 *now* will have more time for 4.0 *tomorrow*. I am not against 3.2, but it is more like "0", unless these questions are positively resolved.

-Markus

 

 

Von: rest-dev [mailto:rest-dev-bounces@xxxxxxxxxxx] Im Auftrag von Jim Krueger via rest-dev
Gesendet: Freitag, 12. Januar 2024 14:54
An: Jakarta Rest project developer discussions
Cc: Jim Krueger
Betreff: [rest-dev] Jakarta Rest 3.2?

 

The purpose of this note is to gauge the interest within the Jakarta Rest community for a RESTful Web Services version 3.2.

 

The primary impetus for this proposed version would be to deliver a version where @Context injection is formally deprecated.   This would require an alternative implementation and all of the corresponding API and TCK changes/additions, but would not remove backward compatibility for current users.    The current plan for Jakarta Rest 4.0 introduces a breaking change by removing @Context injection .   While 4.0 should still focus on that and I’m aware that both the 3.1 specification and Javadoc for the Context class indicate that it will be removed in a “future release”, I’m wondering if it wouldn’t be a good idea to formally deprecate this first, allowing users to see the deprecation warnings and prepare.

 

In addition, at this point it would seem that the likelihood of Jakarta Rest-4.0’s inclusion in Jakarta EE11 is tenuous at best, so producing a more limited 3.2 Version, that still has value add, might be more of a realistic goal along with easing the eventual transition to tighter integration with CDI.

 

Thoughts?