Actually, this problem existed in Servlet spec as well. The only way to
really change things like the InputStream was to wrap and delegate
HttpServletRequest. I've seen this pattern over and over in filter
development. So when the Servlet spec introduces new methods, you're in
trouble compilation-wise (runtime I think it still works?).
Specifications can and should be able to introduce new methods. Its
removing methods or changing behavior that is the real issue, which,
Marek is not proposing here with the changes to Response and Request.
(BTW, on a tangent: with all these changes, WTF do we need Servlets
anymore? JAX-RS is far superior.)
On 9/23/11 7:05 AM, Marek Potociar wrote:
> 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
>>>
>>>
>>>
>>>
>>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com