aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Sirois <jsir...@apache.org>
Subject [PROPOSAL] java gen: Uniform AsyncMethodCallback use in client and server
Date Mon, 08 Feb 2016 19:35:14 GMT
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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message