From: Bill Burke <bburke_at_redhat.com>
Date: Thu, 28 Jun 2012 11:05:05 -0400

On 6/28/12 10:24 AM, Marek Potociar wrote:
> Actually the latest example is what I'm looking at -
> the InvocationCallback generic type itself (and not the generic type of
> the response inside the InvocationCallback generic type). With my change
> the implementations can all rely on the same type-inference code
> implemented in the GenericType, like this:
>
> submit(InvocationCallback<T> callback) {
> // ...execute request..
> Class<?> responseClass = callback.getRawType();
> Type responseType = callback.getType();
>

Why would application code need responseType and responseClass?

> // ...read the response entity as the proper type and invoke the callback...
> }
>
> Without extending InvocationCallback from GenericType (and with a lack
> of any decent type-inference utilities in Java SE), all implementations
> would need to find their own ways of computing the actual callback
> response type, which is not as straightforward as it may seem.
>

With an interface, clients could still do:

class MyGenericCallback<T> implements InvocationCallback<T> {
}

class MySpecificCallback extends MyGenericCallback<String> {}

or just

submit(new MyGenericCallback<String>(){});

or they could just use GenericType:


class MyGenericCallback extends InvocationCallback<Response>
{

    <T> T getEntity(GenericType<T> type)
    {
       response.readEntity(type);
    }
}

or, in the very weird off chance you need to get generic type
information from the callback object itself,

class MyGenericCallback extends InvocationResponse<Response>
{
    public MyGenericCallback(GenericType genericType) {
        this.genericType = genericType;
    }

    public GenericType getGenericType() { return genericType; }

    ...
}


Anyways, a few last questions: Isn't the use case you're describing an
extreme edge case? If so, why are you designing towards a specific edge
case when there are workarounds for that edge case? Why is this
particular edge case more important than the edgecase where you'd want
your callback class to extend an existing application abstract class?

i.e. where you'd want:

class MyCallback extends FooBar implements InvocationCallback<SomeType> {
...
}

There's just so many ways abstract classes constrict class design and
there's simple workarounds for the particular edge case you're designing to.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com