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 can definitely live with having @SuppressWarning in the implementation
code but I don't get why making this change was done few weeks ago only
to manage TCK 1.1 signature tests passing, and what it is to do with 1.1
at all, these changes in 2.0 API, do you understand why ?
Also I agree that if there is some issue there then TCK 1.1 itself needs
to be fixed instead...
Sergey
> BTW, I hate the TCK signature tests in general. For one, Java EE does
> not allow you to upgrade JAX-RS 1.1 to 2.0 within a certified EE 6
> container, even though JAX-RS 2.0 is a standalone spec and is backward
> compatible. The signature tests will fail too. This is something that
> needs to be fixed. I know there are a huge number of customers that will
> want to stick with Java EE 6, but use JAX-RS 2.0.
>
> On 1/17/2013 5:38 PM, Sergey Beryozkin wrote:
>> Hi
>>
>> Comment from Marek at
>>
>> http://java.net/jira/browse/JAX_RS_SPEC-326
>>
>> got me actually concerned, though may be it is unfounded - apologies
>> if so.
>>
>> Basically I do not get why the change to do with JAX-RS 1.1 TCK
>> signature tests was made after JAX-RS 2.0 m10, in fact, different people
>> run TCK 1.1 against CXF JAX-RS 1.1 implementation and it passed, thus
>> I'm worried about this change ?
>> Also - should the actual TCK be 'challenged' and the issue be fixed
>> there instead of pushing it to the API level ?
>>
>> Looking forward to some comments
>> Thanks, Sergey
>