As I said, I have absolutely no problem with breaking backwards compatibility. I would even suggest to break it much more often to provide a clean solution in a new version instead of keeping old problems for decades.
> -----Original Message-----
> From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
> Sent: Freitag, 23. September 2011 13:05
> To: jsr339-experts_at_jax-rs-spec.java.net
> Cc: Markus KARG
> Subject: [jsr339-experts] Re: Proposal for merging
> HttpRequest/HttpResponse with the existing Request/Response API
>
> 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
> >>
> >>
> >>
> >>
> >