jersey
jersey copied to clipboard
eclipse-ee4j
Provide a way to support both jakarta and javax API
Since JAX-RS (Jakarta-RS?) is going to rename the packages from javax namespace to a Jakarta namespace and users would want to use the latest Jersey with their application that they don't want to adapt to a new jakarta namespaced API, it would be desirable to support both jakarta and javax namespaced API.
The possible solutions:
- Abstraction Layer
- Classloading
I do not see why users cannot simply stick with Jersey 2.x LTS? It should be easier to cherry-pick features and release more 2.x releases than adding an abstraction layer which stays in the master branch forever.
Since JAX-RS (Jakarta-RS?)
We've done away with abbreviations ;) So it's either Jakarta REST or just REST.
Since JAX-RS (Jakarta-RS?)
We've done away with abbreviations ;) So it's either Jakarta REST or just REST.
Actually we're not. Everybody is free to call it as he likes unless it is part of an official publication. :-)
So it's either Jakarta REST or just REST.
The official name is "Jakarta RESTful Web Services". Jakarta REST was just a proposal at some point. At least AFAIK.
I actually do not believe anybody here really wants to propose that we MUST use the official name always in our discussions. So can we please simply allow people to say JAX-RS, REST, or whatever they want, as long as we understand each other...? I just have no time for this kind of nitpicking.
The official name is "Jakarta RESTful Web Services". Jakarta REST was just a proposal at some point. At least AFAIK.
Oh yeah, good point. I think everybody agreed, but we hadn't made it official yet. I'll file a bug and mail the PMC after the Holliday season then to make it official.
Oh yeah, good point. I think everybody agreed, but we hadn't made it official yet. I'll file a bug and mail the PMC after the Holliday season then to make it official.
This sounds great. Jersey now supports both JAX-RS (Java EE, Jersey 2.x) and Jakarta REST (Jakarta EE 9, Jersey 3.x) and it is good to distinguish between Jersey 3.x and Jersey 2.x implementation and respective APIs whenever we discuss them, not only in the official texts.
I do not see why users cannot simply stick with Jersey 2.x LTS? It should be easier to cherry-pick features and release more 2.x releases than adding an abstraction layer which stays in the master branch forever.
@mkarg This sounds a bit like you would not want to recommend Jakarta EE 9 & Jersey 3 :) The point is to be able to support for instance MP API and Jakarta EE 9 API. The issue was created a year and half ago, now we have the transformer option, too. Given the short time frame of Jersey 3.x for which the ability was targetted, I do not think the abstraction layer is a big drawback compared to the provided advantage. Jakarta RESTful Web Services 4.0 is scheduled for 2022. and Jersey 4.x would not use that layer any longer. Either way, we do not have a functional POC in Jersey 3.x, yet.
Certainly I like people using Jersey 3, but not as a runtime for javax, but solely for jakarta. I simply explain customers they shall rename the package and nobody had a problem with that so far or they can stick with Jersey 2 as they don't need any new features. So I just do not see the actual need for this. My fear is that an additional layer will provide performance drawbacks or introduce new bugs.
Hello,
I would like to add a bit of context as to why such feature could potentially be useful:
In our organization, we package annotated interfaces in standalone libraries to share REST contracts between teams in our microservice architecture. We have about 1000 such libraries containing only annotated interfaces managed by about 40 teams.
Mandating all teams to release a new version of those libraries using jakarta intead of javax at the same time would be a very inefficient use of resources.
Our platform teams have opted for a maven plugin that generates interfaces annotated with jakarta from interfaces annotated with javax (among other things, it can also generate async apis from sync apis for example)
In the long run we will change our REST contract format to use OpenAPI instead.
The generally accepted approach is to use Eclipse Transformer to convert existing classes consuming javax to consume jakarta dependencies. You can find some articles about that such as the one from Payara.
The goal of this task was to support only javax JAX-RS API (maybe along with a few others such as JSON-B), but not all of them, such as CDI. So the transformer seems to be a better (and possibly a faster - in terms of performance) solution.