If the consensus is this behavior is broken and was a mistake, make it optional in the next iteration of the spec and spec the right way to do it.
Vendors who don’t adopt the right way will still be supported but on notice. The same discussion is going on about removing IIOP-RMI from the EJB spec. At some point in the future you can remove the ‘optional’ items if you like and vendors will have had plenty of notice. There is already precedence for such a strategy in other JavaEE specs.
-Noah
> On Oct 12, 2015, at 8:34 AM, Santiago Pericasgeertsen <santiago.pericasgeertsen_at_oracle.com> wrote:
>
> All,
>
> Markus is correct. There are lot of situations in standards work that backward compatibility should be broken but cannot. The matching algorithm in JAX-RS, with all its good and bad parts, has been around for many years and lots of existing applications rely on it. Making a non-compatible change may cause some applications to break.
>
> As Marek also pointed out, this has already been discussed at the EG level and rejected for the same reason.
>
> — Santiago