Separation of JPMS modules (breaking change)

[mkarg]

For version 4.x of Jakarta RESTful Web Services I'd like to propose that we split the JPMS modules, so in future only those module would get included by applications that actually are needed. This is useful wherever the footprint and bootstrap time plays a role, like in cloud and edge / embedded scenarios.

At least a separation into "client" and "container" is useful, as there certainly are client-only and container-only deployments. Looking a bit deeper it might make sense to identify more modules that could get separated, which is to be discussed.

[chkal]

I like the idea. Although I must confess that I'm not fully sure if I understand all the implications.

[andymc12]

I'd want to think on this a little more before I vote one way or the other, but here are a few other things to consider:

• we would also need a "common" module that includes things required by client and server (i.e. WebApplicationException, MessageBodyReader, etc.).
• it might be nice to split out SSEs into a separate module (or modules - SSE Client / SSE Server?) - SSEs are great, but I think they are somewhat niche and the implementations often require a lot of dependencies.
• that said, I think it might make more sense for implementations to split themselves up along these lines more than the APIs - for example, a vendor could probably implement a fully compliant RESTful client without needing the APIs to be split up (they would just ignore the server APIs - and the excess API footprint should be small).

FWIW, Open Liberty tries to accomplish this last bullet (pre-JPMS) using features. A user could specify the jaxrsClient-2.1 feature if they only need the RESTful client APIs (this feature will be renamed for EE 9). Then the jaxrs-2.1 feature includes the client feature and adds the server capabilities. We could probably be more granular (i.e. make server-with-no-client feature, or SSE-related features), but so far we haven't had many users request this.

Thanks for bringing this up!

[jansupol]

we would also need a "common" module that includes things required by client and server (i.e. WebApplicationException, MessageBodyReader, etc.).

The client needs to be available on the server, too, so to me, it makes sense for the server to depend on the client. The other possibility is to generate two API jars, the way the WebSocket API does, the complete API contains everything, the client API contains just the classes required only by the client runtime. This approach can even be used before 4.0, as it does not break the compatibility.

[mkarg]

I do not see that the server MUST depend of the client. We have many web services running that do NOT consume any other services, so why should they have access to client APIs at all? It is pretty nice to only have Server and Common API and only add a dependency on Client API if actually needed.

[chkal]

@mkarg Just to make sure I understand correctly. So you think we should split up the API JAR into three JARs (common, server, client)? This would be a requirement for getting different JPMS modules, correct?

[mkarg]

@mkarg Just to make sure I understand correctly. So you think we should split up the API JAR into three JARs (common, server, client)? This would be a requirement for getting different JPMS modules, correct?

In fact, JPMS itself demands splitting up the JAR into several JARs (one per module).

I think that common, server, client, would be a good start, but indeed, SSE could be a valid choice for another module. But actually I could imagine that in the end we want many more modules (and: many modules is the idea behind JPMS in general). For example, why should an application programmer have a dependency on RuntimeDelegate? Or maybe MVC might like to depend on just a "low level" set of interfaces ("Servlets++"), instead of all of them? I think if we really look into the use cases of JAX-RS, we will find many modules.

Having a BOM POM ontop we could provide a still easy way to depend only on what you actually want to use.

[chkal]

I agree that splitting up into common, server and client may be a good idea. Not sure if we should split up even more (for separating SSE for example). This could be "too much".

But as mentioned above, I'm not fully sure if there are any implications I'm not aware of.