[
https://issues.apache.org/jira/browse/THRIFT-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15121757#comment-15121757
]
John Sirois commented on THRIFT-3583:
-------------------------------------
Another class of complications comes from collections. Ideally we could adopt
the unofficial offcial java std lib here and use guava
{{Immutable\{List,Set,Map\}}}; however, that leads to all sorts of jar hell
problems for consumers. If we implement our own immutable collections, they'll
both perform worse ~by definition - its a specialized lib - and present an
impedance mismatch to the guava "stdlib" users out there.
In a similar vein, is @Nullable/Optional treatment. Ideally we'd support
modern java coding style here and have nullable fields be represented with
Optional (or at least offfer that as a codegen option), but that requires
raising the floor for compatibility to java 1.8 for the immutable java codegen
option.
> 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)
