search

eclipse-ee4j / jersey

Eclipse Jersey Project - Read our Wiki:
https://github.com/eclipse-ee4j/jersey/wiki
Other
689 stars 351 forks source link

Provide a way to support both jakarta and javax API #4126

Open jansupol opened 5 years ago

jansupol commented 5 years ago

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:

mkarg commented 3 years ago

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.

arjantijms commented 3 years ago

Since JAX-RS (Jakarta-RS?)

We've done away with abbreviations ;) So it's either Jakarta REST or just REST.

mkarg commented 3 years ago

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. :-)

chkal commented 3 years ago

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.

mkarg commented 3 years ago

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.

arjantijms commented 3 years ago

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.

jansupol commented 3 years ago

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.

jansupol commented 3 years ago

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.

mkarg commented 3 years ago

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.

mryan43 commented 10 months ago

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.

jansupol commented 10 months ago

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.