users@jax-rs-spec.java.net

[jax-rs-spec users] [jsr339-experts] Re: Re: Concerns about JAX-RS spec 326

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Fri, 18 Jan 2013 21:35:33 +0000

On 18/01/13 19:22, Marek Potociar wrote:
> FWIW, the whole discussion is NOT (or should not be) about compiler warnings. It is about backward compatibility. That's what signature tests are testing.
>
> For some reason (because generics in Java are a bit screwed up), Class and Class<?> are not EXACTLY the same thing.
Indeed, even I know that :-)
> Anyway, let's wait until I have a final decision from the EE leads and CTS team.
>
No problems,
thanks, Sergey

> Than you for your patience,
> Marek
>
> On Jan 18, 2013, at 11:56 AM, Sergey Beryozkin<sberyozkin_at_talend.com> 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 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
>>>
>>
>>
>