[ https://issues.apache.org/jira/browse/THRIFT-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15121734#comment-15121734 ]
John Sirois commented on THRIFT-3583: ------------------------------------- Noting THRIFT-576 which looks to attack immutability by having 2-state objects with a mutable mode, and a frozen mode triggered with a {{freeze()}} method fwict. > 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|https://github.com/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)