Move Rest Client to Jakarta?

[Andy McCright]

Hi All,

Two posts from me in the same week! What is this world coming to?! :-)

Between this mail list, the Jakarta list, and the CN4J list, there has been a lot of discussion about how to integrate MP technologies with Jakarta.  I don't want to add any noise to those conversations, but I do want to discuss MP Rest Client specifically.

Most folks will agree that if we could go back in time and change things, the idea of a type-safe REST client belongs with JAX-RS (now Jakarta RESTful Web Services, but I'll stick with "JAX-RS" to save typing).  Both JAX-WS and remote EJBs had the concept of a type-safe client as part of their specs.  It's also probably the most requested feature in the JAX-RS space - which says a lot about the success of MP (props to John Ament and Ken Finnigan for kicking the Rest Client project off!).

I am interested in moving the Rest Client over to Jakarta for a few reasons:

1) It logically belongs there. Aside from the reasons above, most MP Rest Client implementations come from JAX-RS implementations (CXF, RESTEasy, Jersey, etc.).

2) It would see greater adoption (while MP is very popular, I think there are several users out there who will only use Jakarta APIs).

3) The JAX-RS community is more active than the MP Rest Client community.  Perhaps that is my fault on the MP side, but there is no denying that the JAX-RS community is very active.  I think it would be nice to have more support at the spec level.

4) The MP Rest Client is pretty much stable at this point. Most of the open issues are requests for TCK test changes and a few requests for very minor items (like adding a portable property for proxy server authentication - good ideas, but not something that is going to cause a lot of code churn).

5) The release cadence would match the rest of JAX-RS. This is fairly huge because it means that the type-safe client would see the same benefits as the regular JAX-RS client without needing a separate MP release.  If JAX-RS adds support for something new and cool (HTTP/3?), then the type-safe client gets it in the same release - and it's tested with the Jakarta TCK, etc.

So this is what I'd like to propose (and get the community's feedback on):

I'd like to take the MP Rest Client 2.0 and integrate it with JAX-RS.  We would remove the RestClientBuilder API, and add methods to JAX-RS's ClientBuilder API to produce a type-safe client. Most of the MP Rest Client APIs are "borrowed" from JAX-RS anyway (@GET, @Context, ClientRequestFilter, etc.), but there are a few MP-specific APIs (@ClientHeaderParam, ResponseExceptionMapper, etc.) that I would like to move to the jakarta.ws.rs.* package space (I know this is controversial, but for the small number of APIs it seems more consistent to use the same package name as other JAX-RS APIs). We would also migrate the spec document into the JAX-RS spec document (probably as a brand new chapter/section) as well as migrate the TCK into the JAX-RS TCK.

None of this would be easy - and of course, it assumes that the JAX-RS community will want to take it, but I think it will be worth it in the end.  

Please let me know what you think.

Thanks,

Andy

[Kevin Sutter]

+1, Andy!  Thanks for taking the initiative and trying to drive this.

As you have pointed out, there is already a lot of discussion about how Jakarta EE and MicroProfile APIs should (ever) merge.  I think by highlighting a very specific, a very self-contained scenario is a great way to flesh out any issues with this process.  I also think that this particular case (merging the MP Rest Client into JAX-RS) is kind of unique from the other scenarios that have been discussed (ie. how to access MP Config from a Jakarta EE specification).  In your case, you are asking about merging a whole MP component into an existing Jakarta specification.  And, you have provided some solid supporting arguments why this is good for MP Rest Client and JAX-RS.

As part of this exercise, I would like to see what the migration impact might be for existing applications that utilize MP Rest Client.  And, what type of tooling would be required to mitigate this migration.  That is, would it be less painful to keep the "microprofile" package name?

Thanks again!

-- Kevin

[Andy McCright]

> I also think that this particular case (merging the MP Rest Client into JAX-RS) is kind of unique from the other scenarios that have been discussed (ie. how to access MP Config from a Jakarta EE specification).  In your case, you are asking about merging a whole MP component into an existing Jakarta specification.

Exactly.  I am a little weary of "being the example" here because I think MP Rest Client is more unique in this aspect.  I definitely would not recommend that we incorporate MP Config under an existing Jakarta specification - if we move it at all (which is also a hotly discussed topic), then my opinion is that it should be in a new Jakarta project.

I also think that due to the uniqueness of Rest Client, we should be able to change package names even if the consensus for other migrated projects is not to change the package names. For example, if the two communities come to terms on MP Config that it should be migrated to Jakarta in it's own project, we should not accept the argument that "well, you all were ok with changing packages for Rest Client - why not Config?".  MP Rest Client would be moving into an existing project with an already-defined package space, whereas MP Config would be moving to a new spec project.  I don't really have a strong opinion either way about changing Config packages - I just don't want somebody to point at my Rest Client proposal as justification to do something that the MP community is not comfortable with.

> As part of this exercise, I would like to see what the migration impact might be for existing applications that utilize MP Rest Client.  And, what type of tooling would be required to mitigate this migration.  That is, would it be less painful to keep the "microprofile" package name?

It would be less painful to keep the microprofile package name, but I think it would be inconsistent.  As for tooling, I think the transformer tool that is currently used to convert EE8 (javax) packages to EE9 (jakarta) could be used to convert MP Rest Client (org.eclipse.microprofile.rest.client) packages to JAX-RS (jakarta.ws.rs).  One thing that I'm not sure if the transformer could do is actually replace the builder - my plan is to remove the (MP) RestClientBuilder class and just add the build(Class<?>) method to the (JAX-RS) ClientBuilder class.

Here are the APIs that are specific to MP Rest Client that would be migrated to the jakarta package space:
@ClientHeaderParam (and it plural annotation) - used for specifying HTTP headers without needing a parameter (useful for JWT or other authentication propagation, etc.)

@RegisterClientHeaders (and the ClientHeaderFactory interface it specifies) - also used for specifying HTTP headers but easier when those headers need to be computed/propagated/etc.

@RegisterProviders - used for declaratively specifying providers used for this client instance - it's an alternative to registering the providers via the builder

@RestClient / @RegisterRestClient - used as decorators for injecting client instances

RestClientDefinitionException - thrown by the runtime when attempting to build an invalid client interface

AsyncInvocationInterceptor (and factory) - a not-so-popular provider primarily used for context propagation - possibly we don't migrate this...

QueryParamStyle - an enum for specifying the format used for multi-valued query parameters

ResponseExceptionMapper - a provider for mapping responses to business exceptions

Obviously, we would need to reach agreement with the JAX-RS community (of which I'm a committer), but my plan would be for each of these classes (with the possible exception of the AsyncInvocationInterceptor) to migrate to jakarta packages, but not be renamed.  And all of the behavior would be the same - no changes to these APIs or javadocs, other than the package.

The TCK would need to change to fit with the JAX-RS TCK, but that won't affect user migration.

Hopefully this answers your questions - thanks for the feedback!

Andy

[Werner Keil]

Andy,

+1 

I think here it would really be a good idea and make life easier as long as the majority of the REST project team (and others who may have to vote on it, but the committers are probably the first based on discussions we have about TLD changes at Jakarta NoSQL and its implementation right now.

Don't forget there already is a package https://jakarta.ee/specifications/restful-ws/3.0/apidocs/jakarta/ws/rs/client/package-summary.html and unless any different package was found better under Jakarta REST it would likely all go there. And There already is a Client and ClientBuilder API element so I am not so convinced about keeping all the names identical, because future applications would have to change dependencies anyway, so why not clean up a few things ;-)

There is no "Rest" prefix anywhere in the Jakarta REST api so calling just one exception "RestClientDefinitionException" while not using the same convention anywhere else feels wrong. I would rename that to "ClientDefinitionException".   Especially since the whole "ClientHeader..." elements don't use the prefix, IMO this was a flaw that could be fixed if such transformation took place.

The @RestClient annotation I admit is the only where calling it @Client in the same package is impossible. Keeping that for the sake of unique name seems reasonable but even @RegisterRestClient IMO should become @RegisterClient because all the other annotations follow a different pattern with @RegisterClientHeaders instead of @RegisterRestClientHeaders for no obvious reason.

Werner

[Rudy De Busscher]

+1 For the integration.

It is mainly a small but very useful addition on top of Jakarta Rest now and is not specific to Microservices in general.

I'm also in favor of changing the namespace as it doesn't impact the MP users a lot. Some of them use the specific annotation -but that can be handled through a breaking change in a major release of MP.

Rudy

[Michał Szynkiewicz]

Hi Andy,

I think it makes sense in the long term.

What I'm afraid of is that it would make it harder to make any changes, especially breaking changes.

I would like to propose some changes to make the spec a better fit for a non-blocking implementation.

But otherwise, as you wrote, it's rather stable at this point, so maybe that's not a big problem.

I chatted with a few of my colleagues. Generally, the move seems okay for most of them.

Some of them expressed doubts whether Jakarta Rest won't get too big. 

Would we want it to be one big spec, or maybe split it to client and server?

Thanks,

Michał

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/f0fd7e22-ca80-4283-9c4a-3484f3cf4e7dn%40googlegroups.com.

[Emily Jiang]

Hi Andy,

I am ok with moving Rest Client from MicroProfile to Jakarta. As for whether to update namespace from microprofile to jakarta, there are cons/pros. Since Rest Client is mature and there won't much changes, I suggest we lock down the current APIs and keep the current namespace to avoid migration (you won't have two same APIs pop up in the IDEs) and retain its originality. Even though there is tooling to help with migration, there will still be overhead and risk associated with it. I don't think end users will be happy to migrate namespaces over and over again. If we want to evolve the current APIs, maybe we should update namespace. However, this proposal is based on that these APIs are stable enough and there should not be changes. If no use cases come up in the Jakarta JAX-RS, I assume these new package and classes will use jakarta namespace.

With the above reasons, I advocate not to update namespace and retain the current org.eclipse.microprofile.*.

Thanks

Emily

[Andy McCright]

Hi Michal,

> What I'm afraid of is that it would make it harder to make any changes, especially breaking changes.

> I would like to propose some changes to make the spec a better fit for a non-blocking implementation.

> But otherwise, as you wrote, it's rather stable at this point, so maybe that's not a big problem.

Yes, perhaps we could put your new non-blocking changes in as part of the migration to JAX-RS?

> Some of them expressed doubts whether Jakarta Rest won't get too big. 

> Would we want it to be one big spec, or maybe split it to client and server?

There has been some discussion around this in the JAX-RS community.  There is some interest in splitting out separate client, server, and common modules for JPMS support.  I'm not sure how that will play out in terms of the actual project, but my guess is that there will still be a single JAX-RS (or Jakarta REST) project, but it will divided up into the three (or potentially more) modules.  

Hi Emily,

> Since Rest Client is mature and there won't much changes, I suggest we lock down the current APIs and keep the current namespace to avoid migration (you won't have two same APIs pop up in the IDEs) and retain its originality.

I think in some cases, it will be easier to do this than others. In order to integrate with JAX-RS, I think we would need to use their existing (jakara) ClientBuilder - and that would replace the (mp) RestClientBuilder.  Otherwise, there is duplication, confusion, dual maintenance, etc.  In other cases, I think it could work - like ResponseExceptionMapper providers and/or @ClientHeaderParam annotations.  Part of the issue with keeping those APIs in MP package space (when migrated to JAX-RS) is that they are meant to be consistent with their existing JAX-RS counterparts - so I think it will lead to some confusion and inconsistency.    

> Even though there is tooling to help with migration, there will still be overhead and risk associated with it. I don't think end users will be happy to migrate namespaces over and over again.

I agree - the overhead for users to change packages is certainly a "con" for my proposal.  However, if we act quickly, I think we can mitigate it so that as users move to EE9, they could make package space transformation in one "big bang" of their own - both to move their javax.* to jakarta.*, but also the org.eclipse.microprofile.rest.client.* to jakarta.ws.rs.client.*.

> If we want to evolve the current APIs, maybe we should update namespace. However, this proposal is based on that these APIs are stable enough and there should not be changes. If no use cases come up in the Jakarta JAX-RS, I assume these new package and classes will use jakarta namespace.

Right - Michal's suggestion of adding some non-blocking support is the only major change suggested for Rest Client.  As I mentioned before, there are other issues, but they should be resolved by adding properties, etc. - nothing substantial for the APIs.

Thanks again for the feedback!

Andy

[Werner Keil]

Emily,

I don't think that's currently possible. Because while it only thought of JCP specs in the "javax" namespace the JESP is quite clear about its namespace and unless modified that also should apply to anything else that's moved into Jakarta EE

> All jakarta namespace development must occur within the scope of a Specification Project operating under the purview of the Jakarta EE Working Group’s Specification Committee and must >implement the process as defined by the most recently adopted revision of the JESP.

Unless the JESP was changed (I raised a ticket https://github.com/jakartaee/JESP/issues/5 and properly migrating a spec would go even further than "consuming" it by Jakarta EE) neither an import of such external spec nor a migration into Jakarta EE seems to work without changing the JESP first if that's even desired.

Frankly given JAX-RS aka Jakarta REST is "prior art" and was around before MicroProfile I would strongly oppose keeping the namespace simply for the sake of backward compatibility with a few users of that relatively isolated MP feature. 

It would alienate the (much bigger, JAX-RS is one of more widely used Jakarta EE specs with over 350 dependencies found in https://mvnrepository.com/search?q=jakarta+rest, doing the same for MP Rest API shows only 50, I won't bother quoting Bintray because we know that's being killed soon by JFrog;-) JAX-RS  developers having to switch between two "client" packages.

Of course there is also a license issue because the Jakart REST API uses GPL with CPE while MP Rest API is under Apache License, but some other APIs like CDI, DI or Bean Validation use Apache only, so a mix between the existing REST codebase and new elements should be possible somehow with more than one license. Keeping the package names separate would not solve that problem either.

Consuming an external spec/API where acceptable is a different thing. Also probably subject to changing the JESP but there at least the governing body of the consumed spec is not going to change to Jakarta EE or its committees.

I saw Andy also voiced in on some of those concerns (less from a Spec Committee perspective) so he already pointed out, that if the migration could happen in a Jakarta EE 9.x (9.1 would be very tight, if there is a 9.2 in October that sounds more realistic) or 10.x release with a ~6 month release cadence, I guess that would allow a swift migration and require apps to change more than just those two package names.

Werner

[Alasdair Nottingham]

Werner,

I read that quoted statement as saying the opposite to what you describe. To me it says that any evolution of code in the jakarta  package has to happen under the Jakarta EE Working Group, not that a Jakarta EE spec cannot define code in a different package. 

Alasdair

--
You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/6fb4948e-22f7-4757-b52c-81adb7ce9fa6n%40googlegroups.com.

[Werner Keil]

Aliasdair,

I disagree on that and having served on the JCP EC for a while I also know (and sometimes helped improve) the JCP document https://jcp.org/en/procedures/jcp2

which states under

>Licensor Name Space: The public class or interface declarations whose names begin with "java", "javax", "com.oracle", "com.sun" (or ?com.Your name? if You are the Specification Lead) or their >equivalents in any subsequent naming convention adopted by Oracle.

And while the JESP may be a little more brief than the JCP document, the mention of "jakarta" IMO is quite similar, so to allow anything continue under a different name space like "org.eclipse" or "?com.Your name? if You are the Specification Lead" this explicitly needs to go into the JESP in an appropriate way.

Werner

[Alasdair Nottingham]

While I don’t have the history of being on the JCP EC that you do I will observe two things:

1. The language JESP does not require the use of jakarta. It just requires the use of jakarta for things that are currently in javax and are being modified. Maybe that was intended, but it wasn’t stated so I think it is a perfectly valid proposal to not change the package. If the Jakarta EE Working Group disagrees they can update the JESP to be explicit that JESP MUST use the jakarta package.

2. The language in the JCP document you reference allows for non java or javax packages, the bit in brackets does that. You have quoted the definition, but not any rules around it and the only rule is that an implementation cannot extend the Licensor Name Space, it doesn’t say that a spec has to define things in a specific namespace. I can only comment on what is in the doc, not what was done or what the JCP EC believed. In any case this isn’t relevant to JESP.

Alasdair

On Feb 10, 2021, at 9:15 AM, Werner Keil <werne...@gmail.com> wrote:

https://jcp.org/en/procedures/jcp2

[Werner Keil]

Yes the JCP document allows more freedom to use e.g. "com.ibm" (in case of Jakarta Batch formerly a JSR) or similar, while the JESP is very specific to migration from "javax" to "jakarta" only.

I created https://github.com/jakartaee/JESP/issues/6 and Ivar also made a brief remark. It seems the JESP would not prevent it. The license terms are clearly something that has to be sorted out anyway if spec, API or TCK were to be donated to Jakarta EE.

As it is an existing Jakarta spec ultimately its project lead or team in Jakarta Rest must decide, if they would want to allow such a package fork or not. If the JESP feels the need to mention other packages than "javax" I guess it may also need amending the JESP, but the ultimate decision lies in the REST project if neither the Jakarta nor MP WG saw a problem preserving the namespace for another reason. Making the wording broader would not be beneficial if we start listing all the possible options, it would simply be something similar to "org.Your name" or "com.Your name".

Werner

[Werner Keil]

The most compelling argument against keeping the old MP package name (not only for Jakarta REST, but at least for all existing Jakarta specs and APIs, it may be different if say MP Config was ever to go there as well;-) is it would create package-splitting.

Jakarta REST has defined a module-info with the current module name `jakarta.ws.rs` even before it came to Jakarta. If this module suddenly exported `jakarta.ws.rs.client` and `org.eclipse.microprofile.rest.client` then any other modules also exporting this package (even if it's an older version of MP with automatic module name from the JAR) could break a modular app that finds both in the classpath/modulepath. That means if a new version of Jakarta REST was polluted that way, any vendor and Jakarta EE runtime that also shipped with an earlier version of MicroProfile would have to eliminate that immediately or force an upgrade to an MP platform without mp-rest-client.

I don't think the MP-friendly Jakarta implementors would like to take that risk.

Werner

[Andy McCright]

Jan Supol brought up an excellent point in the Jakarta REST community - his comment is available here: https://github.com/eclipse-ee4j/jaxrs-api/issues/930#issuecomment-777079152

The issue is that if we move MP Rest Client to Jakarta REST in the 3.1 or 3.2 timeframe (which would be part of EE9.2 or EE10), we wouldn't have an MP Rest Client that worked with EE9 or EE9.1 for the next major release of MicroProfile (presumably 5.0).  We could avoid that if MP 5.0 pulled in EE9.2 (assuming the Rest Client were migrated to Jakarta REST 3.1 / EE9.2) instead.  Otherwise, I think we'd need to release a new version of MP Rest Client (3.0 since it would use EE9) _and_ migrate it to Jakarta REST - which is the kind of duplicated effort I was really trying to avoid - and it perpetuates the problem of package space migration if we choose to change packages...

Andy

[John Clingan]

I have two concerns (below), but I am OK with this if we think the timing is right.

On Tuesday, February 9, 2021 at 7:09:31 AM UTC-8 Andy McCright wrote:

Hi Michal,

> What I'm afraid of is that it would make it harder to make any changes, especially breaking changes.

> I would like to propose some changes to make the spec a better fit for a non-blocking implementation.

> But otherwise, as you wrote, it's rather stable at this point, so maybe that's not a big problem.

Yes, perhaps we could put your new non-blocking changes in as part of the migration to JAX-RS?

This is also one of my concerns. It feels like MicroProfile is a better fit to try out new potential non-blocking APIs and break the API if necessary. Once we think the non-blocking support is stable, then moving to Jakarta feels appropriate.

 

> Some of them expressed doubts whether Jakarta Rest won't get too big. 

> Would we want it to be one big spec, or maybe split it to client and server?

There has been some discussion around this in the JAX-RS community.  There is some interest in splitting out separate client, server, and common modules for JPMS support.  I'm not sure how that will play out in terms of the actual project, but my guess is that there will still be a single JAX-RS (or Jakarta REST) project, but it will divided up into the three (or potentially more) modules.  

There are two concerns for me:

1) We are trying to decompose specifications in Jakarta and it feels like adding a client API to an existing specification is moving in the opposite direction. The Rest Client spec is 42 pages. The Jakarta Rest spec is 87 pages. We would be growing the Jakarta Rest spec by ~50%.  I understand that "pages" is not the best metric, but it was easy to obtain with a few clicks :-) I grok that there may be existing synergies that would reduce overlap when combined. I want to make sure we have sufficient discussion on the general point, though. This ties into my next point.

2) I generally prefer client APIs be tested for compatibility separately from the server. Basically, two TCKs (or TCK subsetting). This enables products to support connectivity to RESTful web services without themselves providing the server API. One example is enterprise integration software, which provides connectivity ("connectors") to backend systems but themselves may not want to provide the server API. However, to claim compatibility a product had to ship both the server and client support. By separating out the client from the server, a product/project can claim client compatibility (and ship only the client) when offering just the client API. I recall having this conversation in the context of JMS in years past, and it was a pain point.

BTW,  I sympathize with the overhead created by these two points, so maybe there is some middle ground.

[Werner Keil]

Andy,

Not sure if you saw my reply just above or overlooked it, but there is no choice unless everyone involved decided it's better to keep it with the MP stack forever.

Take Wildfly as an example (at least other compatible implementations of Jakarta EE like OpenLiberty or Payara should do it almost the same)

WildFly 22 is a compatible implementation of Jakarta EE 8.

WildFly 22 is also a compatible implementation of Java EE 8.

WildFly 22 is also a compliant implementation of the Eclipse MicroProfile 3.3 platform specification.

It's not even there yet with MicroProfile 4, but imagine

WildFly 24, 25 or whichever version implements those combined

Jakarta EE 9.2 with a migrated REST Client under the package namespace "org.eclipse.microprofile.rest.client"

with

A compliant implementation of the Eclipse MicroProfile 4.0 platform specification also containing the existing MP REST Client under the package namespace "org.eclipse.microprofile.rest.client"

BANG, you end up with a deployment failure of an application.

It will not work unless those containers immediately supported the latest MP 5.x platform WITHOUT any trace of "org.eclipse.microprofile.rest.client" and

Jakarta EE 9.2 with a migrated REST Client under the package namespace "org.eclipse.microprofile.rest.client".

Everything else leads to the split package problem and most likely build or deploy failures.

Werner

[Werner Keil]

John,

As for 

> 2) I generally prefer client APIs be tested for compatibility separately from the server. Basically, two TCKs (or TCK subsetting). 

That is a valid point but MP REST does not solve any of that or meet your needs on that.

The problem is that Jakarta EE while many APIs got "alibi module declarations" now like Automatic-Module-Name at the very least, the only Spec that does a proper separation of client and server APIs would be Jakarta WebSocket. It scrapped the automatic module names it had messed up earlier because the project lead or developers did not want to bother with getting it right then, but the separation into Maven modules "jakarta.websocket-api" (the server API)

and "jakarta.websocket-client-api" (the client API)

already does the trick and I would expect a TCK to be modular enough, too allowing to test either of them independently.

MP REST Client does not add any value here because the Jakarta REST Client API is hidden in a package inside a Maven and Jigsaw module "jakarta.ws.rs" instead of that (for the server along the lines of "websocket-api") plus a new module "jakarta.ws.rs.client" (along the lines of "websocket-client-api") with the package "jakarta.ws.rs.client" moved into that module.

Jakarta REST would have to make that separation regardless of how many packages are in the "client" module in the end, there must not be a package split between both for the same reason there also must be no package "org.eclipse.microprofile.rest.client" in two different modules, Maven, Jigsaw or otherwise, that does not matter as long as the package is exposed by two JARs in a class/module path of the same runtime.

Werner

[Andy McCright]

Wrt separating the client and server side APIs/TCKs, I also think that is a good idea - and I agree with Werner that this is something the Jakarta REST community should do - in fact they are considering doing that under issue https://github.com/eclipse-ee4j/jaxrs-api/issues/935

As for the split package issue, it sounds like we really either need to make this happen as soon as possible (1) so that users only have to refactor their packages once and (2) so that MP 5.0 can consume the type safe REST client from Jakarta EE 9.2.  Otherwise, we'd need to release MP Rest Client 3.0 with EE 9 dependencies _and_ migrate to Jakarta REST - which would cause more churn for me (and most vendors) and more migration pain for users. 

John, Kevin, and other WG members, is this something we can plan on?  Specifically, can MP 5.0 depend on Jakarta EE 9.2 (assuming that it includes the type safe REST client) rather than 9.0?

Thanks again,

Andy

[Werner Keil]

I plan to put the modularity on the agenda of the next Jakarta platform call, Andy I saw you joined it at least last time, looking forward to you doing that again.

Werner

[Emily Jiang]

>Specifically, can MP 5.0 depend on Jakarta EE 9.2 (assuming that it includes the type safe REST client) rather than 9.0?

Jakarta 9.1 is not out yet. Jakarta 9.2 has not got a release date yet.  I think we need to figure out how and when to move up to Jakarta EE 9 first before jumping to 9.2. I think we should not rush to commit the migration plan as yet. MicroProfile community needs to work out a plan how to consume Jakarta EE specs quickly and smoothly.

At the moment, we have multiple problems to deal with:

1. Figure out how to make MP specs to be consumed by Jakarta EE: either brand new specs like MP Config or JAX-RS with MicroProfile Rest Client

2. How to make MP align with Jakarta EE specs easily and quickly

I really think we should work out the above two issues in theory before we start putting any timelines with the moving activities.

Thanks

Emily

[Werner Keil]

Another compelling argument to change the package if anything was contributed to Jakarta EE like the Rest Client, because although it might create a little overlap and overhead, a version 5.x or any later version of MP could be based on a Jakarta REST API including the donations while it may keep the old MP Rest Client ideally deprecated then for a transition period. Before it would be removed from MP. That also would not work if the package remains unchanged, aside from all the other dangers of package-splitting.

Werner

[Emily Jiang]

If MP 5.x consumes Jakarta REST API, it will need to remove MP Rest Client for sure. The existing apps using MP REST client will continue to work without needing the package migration.

Emily

[Werner Keil]

You heard today in the platform call, that more implementors of Jakarta EE (all except TomEE which btw. also isn't Jakarta EE compliant yet) use the API artifacts as they are and those contain the Jigsaw module-inf of JAX-RS. Therefore even if a future Jakarta REST version decided to keep that package duplication and accept "org.eclise.microprofile" in its module-info) any MP version prior to an MP "umbrella" (and parent) WITHOUT MP REST Client will fail to work.

So every implementor of Jakarta EE 9.x (or 10 if it didn't make it in sooner) with this package-duplicity under Jakarta REST was immediately forced to upgrade to MP 5 or whenever that might be plausible without a grace period. Or completely remove MP support for a whole release.

According to https://openliberty.io/downloads/ the latest OpenLiberty release that's final also combines Jakarta EE 8 with the older MP 3.x.

That would not be acceptable with package-splitting, if say Jakarta REST came with a "microprofile" package in Jakarta EE 9.2 or 9.3 then Wildfly, OpenLiberty, Payara and every implementor that does not repackage the API JARs and remove the JPMS data will have to support that Jakarta EE 9.x version and MP 5.x immediately at the same time.

So for a tiny bit of nostalgia (all other packages and imports will have to change from "javax" to "jakarta" anyway) 90% of vendors and implementors that wish to support both Jakarta EE 9.x+ and MicroProfile (3 or 4) would have to pay a high price. As the very minimum they all would have to explain their users/developers why what works with Spring Boot very well (see https://dzone.com/articles/how-to-use-java-modules-to-build-a-spring-boot-app and many other examples) will break with Jakarta EE and MicroProfile ;-/

Werner

[Werner Keil]

Some MicroProfile implementors like Helidon make extensive use of JPMS and looking at

https://github.com/oracle/helidon/blob/master/microprofile/rest-client/src/main/java/module-info.java

this could only work if Helidon repackaged the entire MP APIs into its own API-jars containing proper JPMS declarations because the official ones don't contain any not even Automatic-Module-Name (unlike OSGi bundles btw) 

However, even anonymous or unnamed modules with a package name that also comes up in another named module like "jakarta.ws.rs" or similar would fail just as well.

Werner

[m.reza.rahman]

Just checking here - did this ever get much traction? In general I think this was a solid proposal. It would be good to see a bit more modularity of Jakarta REST as part of this. I think things like Jakarta MVC could benefit from that too.

Reza Rahman

Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone

--

You received this message because you are subscribed to the Google Groups "MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/ad7783a2-ce2c-4210-8055-4e7af85cb792n%40googlegroups.com.

[Andy McCright]

Hi Reza,

Yes, it's still on my radar, but I don't think it will happen as quickly as I had hoped.  I was hoping that the type safe client could be a part of Jakarta REST 3.1, and that the next full release of MP (5.0) could use that - effectively moving the Rest Client in one fell swoop.  But I don't think either side is prepared for the move to occur that quickly.  As such, I expect that MP 5.0 will continue to provide a MP Rest Client and Jakarta REST 3.2 (or 4.0) will incorporate the type safe client.  

As for the modularity in Jakarta REST, that conversation is still happening regardless of what is decided regarding the MP Rest Client, and my take is that the community is in favor of splitting up the APIs into client and server (and possibly common for the APIs required by both).

Thanks, Andy 

[Reza Rahman]

Thanks for confirming what I thought was going on. I will continue to keep an eye out and revive this thread if needed after MicroProfile 5.0. Thanks for getting things started.

Reza Rahman

Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.

On Mar 9, 2021, at 6:07 PM, Andy McCright <j.andrew...@gmail.com> wrote:

Hi Reza,

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/b928aa46-ad26-47e2-83f8-4c633644c09fn%40googlegroups.com.

[Werner Keil]

Guess a few of us had hoped it could work with a migration to the "jakarta" namespace, but that ship seems to have sailed now ;-/

Nevertheless the more versions keep popping in the existing namespace "org.eclipse.*" the more important a clean migration to the Jakarta namespace becomes and of course it also makes it easier when e.g. implementations use an older MP version and the new Jakarta EE REST version (whichever that will be) under the same roof to avoid major problems up to deployment failures if that was not done properly. 

So if it has to wait till e.g. Jakarta REST is ready for a 4.0 release, then better a bit later than rushed but messy and potentially error-prone right now.

Werner