Binglin Chang commented on YARN-1871:

Good idea on eliminating PBImpl code, some comments:
bq. Make record class become a non-abstract class, add simple getters/setters 
I like we use simple getter/setter implementation, rather than current complex 
builder/proto/field mixed "cache"
It's better to remain the old API unchanged, and hide implementation. if we can 
generate PBImpl toProto/toRecord, why can't we generate simple getters/setters?

bq. serialization a record to Proto type using reflection
We'd better to generate code, reflection can be used on test code, but I'm 
afraid using reflection to ser/de-ser in rpc code is not acceptable.

bq. There are only some limited patterns in current *PBImpl
There are some complex situations: read only type/property, generic types, 
recursive types and name mismatch in record/proto. When doing YARN-2051, I 
found some situations hard to automate and need special treatment. 

> We should eliminate writing *PBImpl code in YARN
> ------------------------------------------------
>                 Key: YARN-1871
>                 URL: https://issues.apache.org/jira/browse/YARN-1871
>             Project: Hadoop YARN
>          Issue Type: Improvement
>          Components: api
>    Affects Versions: 2.4.0
>            Reporter: Wangda Tan
>            Assignee: Wangda Tan
>         Attachments: YARN-1871.demo.patch
> Currently, We need write PBImpl classes one by one. After running "find . 
> -name "*PBImpl*.java" | xargs wc -l" under hadoop source code directory, we 
> can see, there're more than 25,000 LOC. I think we should improve this, which 
> will be very helpful for YARN developers to make changes for YARN protocols.
> There're only some limited patterns in current *PBImpl,
> * Simple types, like string, int32, float.
> * List<?> types
> * Map<?> types
> * Enum types
> Code generation should be enough to generate such PBImpl classes.
> Some other requirements are,
> * Leave other related code alone, like service implemention (e.g. 
> ContainerManagerImpl).
> * (If possible) Forward compatibility, developpers can write their own PBImpl 
> or genereate them.

This message was sent by Atlassian JIRA

Reply via email to