| Re: [rest-dev] Jakarta Rest 3.2? |
I'm a +1 for this plan. I think having a real depreciation of @Context and the ContextResolver interface is really helpful for users. I don't think most users read the specification and I truly feel it will catch users by surprise that the types are no longer there. It also allows projects like MicroProfile to adopt the specification without breaking changes. I understand the specification noted this and there is in a note in the @Context JavaDoc, but there is nothing on the ContextResolver interface. Adding a @Deprecated(forRemoval = true) annotation on these types would be very helpful IMO.
With this plan, I'd like to request a minimum Java level of Java 17. This would be consistent with all other specifications with the exception of Jakarta Concurrency (Java 21) and CDI (Java 11).
On Fri, Jan 12, 2024 at 5:54 AM Jim Krueger via rest-dev <rest-dev@xxxxxxxxxxx> wrote:_______________________________________________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?
rest-dev mailing list
rest-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
--_______________________________________________James R. PerkinsJBoss by Red Hat
rest-dev mailing list
rest-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org