@khanimteyaz Thanks for your attention, I will try to explain.

As you may have noticed, we support a service definition with a 
CompletableFuture as the return type.
```java
public interface AsyncService {
    CompletableFuture<String> sayHello(String name);
}
``` 

But this is newly introduced in 2.7.0, which means, there would be many legacy 
services that can not leverage this feature. Because if they change the service 
definition (the interface definition) they will have to reimplement their 
service to meet the new definition.
For example, here is a typical service definition before 2.7.0
```java
public interface GreetingsService {
    String sayHi(String name);
}
```
To be able to call this service asynchronously, they have use `RpcContext` to 
get the `Future`, like this:
```java
// the invoke will return null immediately
greetingsService.findFoo(fooId);
// get the Future instance, the future will get notified once the result 
returns.
Future<Foo> fooFuture = RpcContext.getContext().getFuture();
```
Annotation @AsyncFor is a mechanism I introduced to simplify the process for 
those legacy services, you can refer to 
[here](https://github.com/dubbo/dubbo-async-processor/tree/deprecated-processer)
 for how it works.

But now, as long as I realized we have supported java 8, we can use the default 
method to avoid generating a new class. 
[Here](https://github.com/dubbo/dubbo-async-processor/blob/master/README.md) is 
the new way I have come up with, this is what mean by saying `move the 
@AsyncFor from core to side project '. This way, this would become a convenient 
solution we provide but not a mandatory solution provided in core.

[ Full content available at: 
https://github.com/apache/incubator-dubbo/pull/3095 ]
This message was relayed via gitbox.apache.org for 
[email protected]

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to