[
https://issues.apache.org/jira/browse/THRIFT-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15121850#comment-15121850
]
Benjamin Gould commented on THRIFT-3583:
----------------------------------------
I have an example of set of immutable structures using Swift also... please
note there is graphic abuse of generics and viewer discretion is advised ;)
https://github.com/bgould/thriftee/tree/master/thriftee-core/src/main/java/org/thriftee/compiler/schema
Basically the pattern that I used is to create a builder class for each
struct... then you build a tree of builders which in turn can then create the
tree of immutable objects. I'm able to use vanilla java.util.Collections here
fwiw.
This strategy led to very ugly code for the structs, which SHOULD be handled by
a code generator I think. If I were to generate these structures via a code
generator I probably wouldn't need the complicated use of generics.
If there is a solution I'd look forward to ripping out these structures from my
code and replacing them with proper Thrift-generated ones, so I'd be glad to
contribute/test if that is helpful.
BTW John - off topic - I see you are using the Swift IDL parser in your code;
not too long ago I contributed an XML generator (THRIFT-3523) for the Thrift
compiler that provides all of the same information about your IDL as the Swift
parser (one reason that I developed it was to remove that dependency in my own
project). It is fairly easy to integrate into Java using JAXB - if you are
interested here are the XSD and JAXB binding that I use:
https://github.com/apache/thrift/blob/master/lib/xml/thrift-idl.xsd
https://github.com/bgould/thriftee/blob/master/thriftee-core/src/main/resources/org/thriftee/thrift/xml/thrift-idl.xjb
> 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)
