Clarify liberty of implementations to provide separate client and server jars

[spericas]

Although the API jar cannot be split, most implementations do provide separate jars to avoid always referencing a large JAR containing all classes. For example, a JAX-RS client only application does not need server classes from the implementation.

It was suggested that this should be explicitly allowed by the spec: Here is some text that we can use for that,

_

An implementation of JAX-RS must provide all capabilities required by this specification, but may package the capabilities so that an application need only include either the client capabilities of the server capabilities. If the client capabilities are not included but are used, the following APIs will fail in the following manner. If the server capabilities are not included but are used, the following APIs will fail in the following manner.

_

[arjantijms]

+1

For a 3.0 release we could even investigate to see if must would be an option for separate server and client jars.

[spericas]

@arjantijms Yes, exactly.

[mkarg]

I have not understood what is the problem with providing the complete JAX-RS API JAR? Isn't it enough to simply use Java 9 modules to restrict classloading?

[spericas]

@mkarg I don't understand your question. This issue is really about implementation jars.

[asoldano]

Why do we really need to mention this in the spec? Only because in future we want to explicitly mandate how the implementations have to be split?

[spericas]

@asoldano No, we shouldn't do that. I've been told that, technically, splitting implementation jars was not allowed under the JCP rules (not sure where that's stated to be honest). Less of an issue going forward, but it does not hurt to be explicit.

[bshannon]

Let me briefly explain the compatibility issue. If you want more detail, move this discussion to email. I recognize that the Jakarta EE compatibility rules might be different than the JCP compatibility rules and so none of this may apply in the future.

The JCP spec requires you to pass the TCK. Passing the TCK includes meeting non-tested requirements that are part of the TCK. We call these the compatibility rules.

The compatibility rules require that you do what the spec says you have to do, in all supported configurations. If running with only a client jar is a supported configuration, then that configuration has to do everything the spec requires. Obviously that's a problem if the spec requires server support. (Don't get hung up on the word "support" - if you tell people how to do it, it's "supported".)

The way around this is to change what the spec requires, and explicitly state that certain subset configurations are supported, and describe how they must behave.

Again, if that's not enough explanation, please move this discussion to email.

[chkal]

Just to fully understand this. The proposal is to not only explicitly allow to split implementation jars into client and server but also to define how APIs must behave if the corresponding implementation JAR is missing?

[spericas]

@chkal I wouldn't think we need to go that far. Seems to me that it is sufficient to introduce this notion of supported configurations.

[chkal]

@spericas Ok. I got this impression from the following formulation:

If the client capabilities are not included but are used, the following APIs will fail in the following manner.

But I agree that this would go too far.

[bshannon]

You would need to specify how the APIs behave in all supported configurations. Hopefully there's a well-defined exception that is thrown when you try to use something without a corresponding implementation.