[
https://issues.apache.org/jira/browse/THRIFT-3583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15132978#comment-15132978
]
John Sirois edited comment on THRIFT-3583 at 2/4/16 8:41 PM:
-------------------------------------------------------------
Adding another blocker related to THRIFT-2157 and the {{ISerializable}}
refactor. This is another class of {{ClassCastException}} s on the
{{onComplete}} path (THRIFT-2157 deals with a {{ClassCastException}} on the
{{onError}} path).
was (Author: jsirois):
Adding another blocker related to THRIFT-2157 and the {{ISerializable}}
refactor. This is another class of {{ClassCastException}}s on the
{{onComplete}} path (THRIFT-2157 deals with a {{ClassCastException}} on the
{{onError}} path).
> 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
> Assignee: 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)
