External library to generate the remote service's Async interface

[Cristiano]

Hello all,

we are using an annotation processor to generate the async interfaces that are required by the GWT RPC services. This annotation processor automatizes the generation and works smoothly both with the maven build and on the IDE, plus we have other generation requirements and we have then added some more options to customize the output. Code generation is triggered by adding the @Asynchronize annotation to the original interface.

We have released it open source, on https://github.com/codejuicer/asynchronize and the first public release is already available and published into Maven Central repo:

<dependency>

    <groupId>org.codejuicer</groupId>

    <artifactId>asynchronize-processor</artifactId>

    <version>0.9.1</version>

</dependency>

Here is a Youtube video overview I have made to show how to use the processor and what it does (but generically it is sufficient to add this dependency and put @Asynchronize to make it work). 

We would like it to be used for future GWT, so we ask please the main contributors to have a look and give feedback, report issues (on github!) or ask documentation clarification so we can improve it for GWT developers needs.

Thank you all,

Cristiano

[Matic Petek]

Hi,

  Your video is private. 

[Cristiano]

thanks!

it should be ok now

https://youtu.be/YC853Kkm_6E 

[Jens]

Hey,

I actually also thought about that in the past but never had time to implement it. You can read my thoughts at https://groups.google.com/d/msg/codehaus-mojo-gwt-maven-plugin-users/tSI4ZqjNZD8/uMt0TMHW2sUJ

Basically instead of @Asynchonize I would have used @RemoteService as that matches the "old" interface name you currently have to extend. Also I would have introduced a @GenerationStrategy annotation because in the Async interface you can return void, Request or RequestBuilder which allows you to customize the request or even cancel it.

-- J.

[Thomas Broyer]

IMO, it should be possible to set the "returnType" on each method of the interface, so you could have an async method returning 'void', another one returning 'Request' and yet another returning 'RequestBuilder', all in one interface. Same could be useful for the callback type too (and actually probably all the options you provide).

I had long thought about using RemoteServiceRelativePath to trigger an annotation processor, but I would have to come up with some annotation to define the return type. In the end, it's probably easier to generate the sync interface from the async one: all you have to do is to decide whether you want the boxed or primitive types when your callback takes a boxed type as type-argument (e.g. AsyncCallback<Integer>), but it wouldn't be a real issue in practice I believe to always pick the type-argument as-is and never convert to the primitive type.

On Monday, September 14, 2015 at 2:50:02 PM UTC+2, Cristiano wrote:

[Cristiano]

Hi Jens,

yeah, basically I do what you wanted to do with @RemoteService, but then I had to rearrange the dependencies (moved in a project where I couldn't depend on GWT) and so I moved to processing on the @Asynchronize annotation (which I created initially with a different name and purpose similar to your @GenerationStrategy).

And yes there is the possibility to customize the return type, for example if you want a boolean, use it as @Asynchronize(returnType = boolean.class). Plus there are some other inspiring options.

I really think that being an independent project it makes it better in terms of modularity, 

but its code is Apache Licensed and I allow freedom of copying it to make a processor specific for GWT, working with @RemoteService annotation.

Also I have some ideas (see the github issues) to make it completely transparent as a dependency so that subprojects don't inherit the processor and processing is not triggered in all the hierarchy.

Please give it a try, your feedback could be helpful ;-)

[Cristiano]

Hi Thomas,

now that the processor project is setup, updating it to allow each specific method to customize the return type or callback is tricky. OfCourse, the method needs to be someway annotated.

If you plan to try to use the processor, please add an issue on github and I'll be pleased to implement it.

Regards,

Cristiano

[Lars]

What is the plan do deal with custom classes (including inheritance and generics) as a parameter or return type?

[Cristiano]

Could you write an an example to explain better what you mean, please?

Thanks

[Lars]

All your samples deal with primitive stuff or collections of this. For a real RPC we need custom objects as well and a way to transfer them, but as I see it right now you generate only the async interface?!

[Cristiano]

Hi,

there is no problem in using a custom object, the characteristic of the examples with collections or maps is that they TEST the use of Generics: the generic parameter must be reused correctly in the Async interface.

I've added a new example with a CustomObject to the asynchronize-example project to show that using a custom object is not a problem.

Please consider that the processor only generates the interface, but then it need to be used with a real RPC implementation like GWT RPC.

I am considering to release an RPC implementation library based on HTTP and GSON, but it is pure Java, it works with Android but it does not work with GWT (we use the same async interface both on the Android client and GWT client, so we can better reuse code logic and handle with the same code the (asynchronous) requests to the server), but I do not foreseen to release it soon...

Regards,

Cristiano

[Lars]

Ok! This makes sense, but normal the IDE now creates this Async interface and keeps this in-sync ...