jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: Proposal for merging HttpRequest/HttpResponse with the existing Request/Response API

From: Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com>
Date: Wed, 21 Sep 2011 15:24:17 -0400

On Sep 21, 2011, at 1:10 PM, Markus KARG wrote:

>> While the proposed changes introduce a risk of BW incompatibility, the
>> ...
>> FWIW, we have already checked our intent within the JavaEE architects
>> and spec leads group and while personal opinions
>> of individual spec leads are divided, we are free to proceed with the
>> change at our own discretion.
>
> Strange. I once read on this list that we must not induce ANY backwards incompatibility. Can you elaborate why THIS one is different?

 I recall a couple of discussions around this. One in relation to deprecation and pruning, which is obviously not the case there. There was another about the difference between interfaces targeted to be implemented by applications vs. implementations/frameworks.

 Proposing a change to an application interface like MessageBodyWriter would be out of the question. Neither Response nor Request are really intended to be implemented by applications; however, there is no language construct nor an annotation that prevents/warns developers of that.

 So the question becomes, given the nature of Request/Response and the uses of these interface/abstract class in the wild, do we want to accept the consequences of modifying them in 2.0 or do we want to live with 2 pairs like Request/Response and HttpRequest/HttpResponse?

-- Santiago