Proposal: improve type compatibility with dubbo-java

[felix021]

Background

Java has similar types.

Take the following method as example:

i64 Echo(1: i64 req)

In dubbo-java, it can have several forms.

The following form requires type J:

long EchoInt64(long req)

While the following form requires type java.lang.Long:

Long EchoInt64(Long req)

Problem with codec-dubbo

The current implementation of codec-dubbo is to generate J for int64 and java.lang.Long for *int64.

For i64 fields with in a type, the generated Go type can be specified by the required/optional attribute: required -> int64, optional -> *int64; but the attribute is NOT available for the type of request/response arguments.

So, with the current codec-dubbo implementation, Kitex can only be compatibile with the first form (with longs).

Other confusing types include:

• List (java.util.List), ArrayList (java.util.ArrayList)
• Map (java.util.Map), HashMap (java.util.HashMap)
• ...

Plan

The plan needs to be further refined.

So we need to implement a mechanism for user to specify the type generated when encoding, to be compatible with dubbo-java.

Fields within a struct

Dubbo-Java only requires the types of arguments being sent, so there's no need to deal with the fields within a struct.

Method Arguments

For the requesttypes, we need more complex format for the annotation of the method.

For the following Thrift IDL:

service TestService {
    i64 EchoInt64(1: i64 req, 2: i64 req1) (hessian.req="type:int64,int64"),
}

Update: in #54 we decided to use the tag hessian.argsType="type1,type2"

Thriftgo will generate (with option -thrift with_reflection, more details):

[felix021]

fastCodec (#28) should solve this