commit	17fa9b2b04bfdc14cf61d2aaf89d4a4af964e9c6	[log] [tgz]
author	ken.lj <ken.lj.hz@gmail.com>	Sat Dec 29 17:06:48 2018 +0800
committer	GitHub <noreply@github.com>	Sat Dec 29 17:06:48 2018 +0800
tree	b01d695915d3fed9adfa54d2f33eed4ddf6c6027
parent	07b396a287602853107ea68be16110558feb9309 [diff]

tree: b01d695915d3fed9adfa54d2f33eed4ddf6c6027

README.md

Introduction

There will have two parts in this repo

AsyncSignal class specially designed to distinguish async method.
A compiler hacker processer that is able to generate async counterpart for each method in you Dubbo service interface.

AsyncSignal

AsyncSignal is an optional convenient type provided to unify your service definitions.

Imagine you have a Dubbo service defined like this:

public interface GreetingsService {
    String sayHi(String name);
}

Add an overwrite counterpart method.

public interface GreetingsService {
    String sayHi(String name);
    
    // AsyncSignal is totally optional, you can use any parameter type as long as java allows your overwrite.
    default CompletableFuture<String> sayHi(String name, AsyncSignal signal) {
        return CompletableFuture.completedFuture(sayHi(name));
    }
}

Now, you can call the new method with the CompletableFuture signature directly on Consumer side.

Compiler hacker processer

It should run at compile time, and overwrite each method in your service definition with an async equivalence. I think we can try to realize it by referencing lombok.

Conclude

The essential part is to overwrite a new async method. Another way would be to generate a new method with a different name, for example, sayHiAsync, then we can get rid of AsyncSignal. But there's an obvious flaw of this way, that is, all method level configurators and routers defined to sayHi will not take effect.