I've filed an issue that proposes either adding an option to the `java` gen lang or else adding a new gen kang (ala `javame`) that effects generation of immutable thrift structs and unions for java: https://issues.apache.org/jira/browse/THRIFT-3583
I have positive feedback from the Apache Aurora project where I conducted a full working experiment with the idea ( http://markmail.org/message/a6sdqcelgokw6mwz) and some initial positive feedback on the thrift ticket. Before proceeding to draw up patches, I'd like to vet a few possible paths here and generally gauge the community stance. >From what I can tell, there are 3 primary challenges implementing an option to generate immutable entities - in order from most daunting to least: 1. The thrift java support library is fundamentally mutable. It starts in TBase, where you need an instance before you can `read` it from the wire, you can `reset` it and you can `deepCopy`. The latter is not problematic, but the former are. It seems like, assuming the immutable option were to leverage the existing thrift java lib, the TBase interface would need to be decomposed into a read interface and a write interface and then TBase would need to be built back up on top of those to maintain backaward compatibility but open a seam to introduce the new object model. 2. The java standard collection library is fundamentally mutable. Its true, you can just use Collections.immutable{List,Map,Set} but it would be nice to communicate immutability in signatures - notably using guava's Immutable{List,Map,Set} - as well as leverage the performance optimizations they've invested so much time in. Using guava though would present a jar-hell situtation for thrift's consumers. We could roll our own immutable collections - or interfaces - but this presents an impedance mismatch problem for those using guava. 3. The java standard library for older versions of java (<=1.7) is fundamentally nullable. It would be wonderful to present the option of representing nullable fields as Optional. Unfortunately the java stdlib doesn't carry this until present - 1.8. Again there is the option of using guava's Optional with the associated jar-hell problem. And also the roll our own option with the same impedance mismatch issues. I'd prefer to leverage the thrift java library and attempt the splitting described in 1. For 2 I think there is not much to do except accept the java mutable collection interfaces. For 3 I'd love to set the floor of support at java 1.8 for the immutable code. If folks agree the feature is desirable, and some form of the described splitting in 1 is a good path (maintain but restructure the existing thrift java lib), I'd further propose the change land as several patches. The library splitting could certainly land as 1 or more changes with no immutable implementation to start, but I'm not sure what development style the project prefers. I appreciate any and all feedback from interested folks!
