The use case we are considering to break was never explicitly supported and it was never meant to be supported by
JAX-RS. What exactly do you suggest we should actually do?
Marek
On 09/22/2011 08:02 PM, Markus KARG wrote:
> For my case, I have no problem with breaking backwards compatibility as I
> tell everbody to recompile and test all stuff with every new release of a
> specification anyways as there always could be subtle changes. But, Java EE
> spec must clearly tell that 1.x will not be supported anymore in that
> particular area for those programmers that (why ever) used that stuff.
>
>> -----Original Message-----
>> From: Santiago Pericas-Geertsen
>> [mailto:Santiago.PericasGeertsen_at_oracle.com]
>> Sent: Mittwoch, 21. September 2011 21:24
>> To: jsr339-experts_at_jax-rs-spec.java.net
>> Subject: [jsr339-experts] Re: Proposal for merging
>> HttpRequest/HttpResponse with the existing Request/Response API
>>
>>
>> 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
>>
>>
>>
>>
>