[PROPOSAL] java gen: Uniform AsyncMethodCallback use in client and server

[John Sirois <js...@apache.org>]

I'd like to propose a breaking change in both the java generated service
code and in supporting library code.  This change would change
parametrization and use of clients to be symmetric with servers in the java
async stack.

Today the situation is as described in comments in
https://issues.apache.org/jira/browse/THRIFT-3112.
Although you might expect an async client call that returns an int to look
like:
  `client.add(int first, int second, new AsyncMethodCallback<Integer>()
{...});`

It in fact looks like:
  `client.add(int first, int second, new AsyncMethodCallback<add_call>()
{...});`

Where `add_call` is a type with an `int getResult() throws ...` method the
client must call in the `AsyncMethodCallback.onComplete` implementation to
retrieve the result of the async call, or else its remote error.

This has been the case since initial commit in 2010, but there are several
shortcomings, chief among these being:
1. The parametrization is highly un-expected.  Its neither the expected
return type (like the server parametrization) nor a type at the same
abstraction level as the decalring AsyncIface - its a type encapsulated by
the AsyncClient _implementation_.
2. Because of the coupling to implementation in 1, we are not as free to
modify the library implementation or generated code as we might be in a
world where the AsyncIface was composed purely of standard value types
(structs, ints, etc).

It seems to me it would be wonderful to take our pre 1.0.0 status to
correct this confusing and leaky API.

I'm interested in what folks think.

Re: [PROPOSAL] java gen: Uniform AsyncMethodCallback use in client and server

[John Sirois <jo...@conductant.com>]

Sorry folks - wrong list!  Please disregard.

On Mon, Feb 8, 2016 at 12:35 PM, John Sirois <js...@apache.org> wrote:

> I'd like to propose a breaking change in both the java generated service
> code and in supporting library code.  This change would change
> parametrization and use of clients to be symmetric with servers in the java
> async stack.
>
> Today the situation is as described in comments in
> https://issues.apache.org/jira/browse/THRIFT-3112.
> Although you might expect an async client call that returns an int to look
> like:
>   `client.add(int first, int second, new AsyncMethodCallback<Integer>()
> {...});`
>
> It in fact looks like:
>   `client.add(int first, int second, new AsyncMethodCallback<add_call>()
> {...});`
>
> Where `add_call` is a type with an `int getResult() throws ...` method the
> client must call in the `AsyncMethodCallback.onComplete` implementation to
> retrieve the result of the async call, or else its remote error.
>
> This has been the case since initial commit in 2010, but there are several
> shortcomings, chief among these being:
> 1. The parametrization is highly un-expected.  Its neither the expected
> return type (like the server parametrization) nor a type at the same
> abstraction level as the decalring AsyncIface - its a type encapsulated by
> the AsyncClient _implementation_.
> 2. Because of the coupling to implementation in 1, we are not as free to
> modify the library implementation or generated code as we might be in a
> world where the AsyncIface was composed purely of standard value types
> (structs, ints, etc).
>
> It seems to me it would be wonderful to take our pre 1.0.0 status to
> correct this confusing and leaky API.
>
> I'm interested in what folks think.
>



-- 
John Sirois
303-512-3301