Skip to main content

[jsr339-experts] Re: [jax-rs-spec users] Re: InvocationCallback changing?

  • From: Bill Burke <bburke@...>
  • To: jsr339-experts@...
  • Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: InvocationCallback changing?
  • 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




[jsr339-experts] InvocationCallback changing?

Bill Burke 06/26/2012

[jsr339-experts] Re: InvocationCallback changing?

Marek Potociar 06/27/2012

[jsr339-experts] Re: InvocationCallback changing?

Bill Burke 06/27/2012

[jsr339-experts] Re: InvocationCallback changing?

Bill Burke 06/27/2012

[jsr339-experts] Re: [jax-rs-spec users] Re: InvocationCallback changing?

Marek Potociar 06/28/2012

[jsr339-experts] Re: [jax-rs-spec users] Re: InvocationCallback changing?

Bill Burke 06/28/2012

[jsr339-experts] Re: [jax-rs-spec users] Re: Re: InvocationCallback changing?

Marek Potociar 06/28/2012

[jsr339-experts] Re: [jax-rs-spec users] Re: Re: InvocationCallback changing?

Bill Burke 06/28/2012

[jsr339-experts] Re: [jax-rs-spec users] Re: Re: InvocationCallback changing?

Bill Burke 06/28/2012
 
 
Close
loading
Please Confirm
Close