On Nov 11, 2009, at 5:21 PM, gerard davison wrote:
>
>
> On 10/11/2009 15:39, Paul Sandoz wrote:
>>
>> On Nov 10, 2009, at 4:05 PM, gerard davison wrote:
>>
>>> but I am not sure it would be required if the interface is
>>> properly generic).
>>>
>>
>> Agreed it should not be required. But GenericEntity can still be
>> useful if T = Object.
>
> Can you give an example of this? Won't most cases work with just a
> cast as you already know the type for a generic entity.
>
@GET
public Object get() {
}
Object can be an instance of Response, GenericEntity or something
else. GenericEntity is also useful on the client side.
>>
>>
>>> I guess I am going to have to wait until 2.x for this. As to a
>>> workaround, it would be useful the WADL issue, I guess it could as
>>> simple as a generic subtype of these classes. I guess I will log
>>> that with the root issue which stated this discussion, hopefully I
>>> will have this done in a few days.
>>>
>>
>> I can add support for GResponse<T> and GResponseBuilder<T> in
>> Jersey. Ideally i would like those to inherit from Response and
>> ResponseBuilder but i am not sure that is possible because of
>> method ambiguity. Given that the simplest thing is to duplicate the
>> functionality and enable Response to be created from GResponse.
>
> In order for this to work in the WADL case the build method needs to
> return GResponse<T> so it can be used in the interface of the class.
Yes.
> Covariant return types should make it possible to create a subclass
> of ResponseBuilder that returns a more specific type.
>
To the caller methods will be ambiguous:
public abstract class GResponse<T> extends Response {
public static <T> GResponseBuilder<T> status(int status) {
...
}
...
}
The following line will not compile:
GResponse<String> r = GResponse.<String>status(200).build();
Paul.