Uploaded image for project: 'Thrift'
  1. Thrift
  2. THRIFT-3583

Add support for generating immutable java stubs for structs and unions

    XMLWordPrintableJSON

    Details

    • Type: New Feature
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      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 and implemented here. Performance improvements for the Aurora use cases are documented here.

      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 and flows from there up through the deserialization stack. 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!

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                jsirois John Sirois
                Reporter:
                jsirois John Sirois
              • Votes:
                0 Vote for this issue
                Watchers:
                8 Start watching this issue

                Dates

                • Created:
                  Updated: