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
>
>
>
>