On Jan 21, 2013, at 6:11 PM, Bill Burke <bburke_at_redhat.com> wrote:
>
>
> On 1/18/2013 5:56 AM, Sergey Beryozkin wrote:
>> Hi Bill,
>> On 17/01/13 22:48, Bill Burke wrote:
>>> Not sure I understand the issue, but IMO, the TCK should be challenged
>>> if a backward compatible method signature change was done. For example,
>>> Java 5 had a huge number of backward compatible signature changes
>>> because of generics. Java EE should be the same.
>>>
>> I'll provide some more info. I've upgraded to 2.0 m10 API few months
>> ago, and I did not have to change UriBuilder methods accepting Class
>> parameters, the parameters were in the form "Class<?>" as far as I recall.
>>
>> After upgrading to 2.0 m15 API I'm seeing Eclipse saying CXF
>> UriBuilderImpl does not override something, after converting "Class<?>"
>> to "Class" it started compiling with me having to also add
>> @SuppressWarning due to "Class" being not typed with a type parameter
>> which is not cool at all - haven't you seen it yourself in RestEasy ?
>>
>
> I haven't updated Resteasy to latest jax-rs 2.0 API in awhile. I'll be doing it this week and will have a lot more feedback on spec changes probably.
Just keep in mind that we're approaching the point of no return... We should not be making any significant changes at this point, so whatever you want to still get addressed in JAX-RS 2.0, now it is high time. Please, understand that our (spec lead) cycles as well as the cycles of the TCK team are limited.
Thanks,
Marek
P.S. One thing I still want to get resolved is client security config. Every other improvement or feature is IMO not critical anymore.
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com