John Sirois created THRIFT-3583:
-----------------------------------

             Summary: Add support for generating immutable java stubs for 
structs and unions
                 Key: THRIFT-3583
                 URL: https://issues.apache.org/jira/browse/THRIFT-3583
             Project: Thrift
          Issue Type: New Feature
          Components: Java - Compiler, Java - Library
            Reporter: John Sirois


In certain domains and depending on consuming project coding style, having 
thrift entities (structs and unions) be immutable by default is advantageous to 
both reasoning about code safety and correctness as well as certain performance 
optimizations.  An example of such a domain/project is found in Apache Aurora 
which uses thrift to define its core data model, RPC API and as its medium for 
stable storage serialization.  Aurora must ensure thrift structs used as keys 
in sets and maps are immutable and it must be able to perform bulk calculations 
against these objects efficiently.  Both requirements are hindered by the 
thrift java generated code which is fundamentally mutable.  Today Aurora works 
around this by generating immutable wrappers with a custom python script, but 
ideally it could just say {{thrift --gen java:immutable}} or {{thrift --gen 
java_immut}} and opt in to immutable generated entities.  An experiment writing 
an immutable code generator using the Facebook swift library is discussed 
[here|http://markmail.org/message/a6sdqcelgokw6mwz] and implemented 
[here|https://reviews.apache.org/r/42748].  Performance improvements for the 
Aurora use cases are documented [here|https://goo.gl/gR8zgu].

The concrete proposal is to add a new mode of java codegen (I think a new gen 
lang, like {{java_immut}} will probably be needed vs another option to the 
existing {{java}} gen lang) that generates immutable thrift entities.  This is 
harder than it sounds given the goal of leveraging the existing java support 
lib as much as possible since the existing supporting thrift java lib assumes 
mutable entities at its core with wide ripple.  This starts in 
[TBase|https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/TBase.java#L37]
 and flows from there up through the [deserialization 
stack|https://github.com/apache/thrift/blob/master/lib/java/src/org/apache/thrift/TDeserializer.java#L70-L86].
  Although not insurmountable, some thought will need to be given to a 
restructuring of these mutable-assuming APIs into read and write parts that the 
existing interfaces can be re-composed on top of to make way for the immutable 
option.  The alternative is to write a whole new support lib like {{javame}} 
has done - not a 1st choice!
 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to