Optionally suppress generated Builder types

// Let's call this example.thrift

namespace java com.foo.bar

struct Query {
  1: required string text,
  2: optional i64 resultsNewerThan
}

struct SearchResult {
  1: required string url,
  2: required list<string> keywords = [], // A list of keywords related to the result
  3: required i64 lastUpdatedMillis // The time at which the result was last checked, in unix millis
}

service Google {
  list<SearchResult> search(1: Query query)
}

In the example above we need builder only for Query as the value for the search result is populated by deserializer. Looking at the code there is no easy way to distinguish if the model is request/response type. Any idea on how to go around it?

[benjamin-bader]

This sort of thing would apply to structs, unions, and exceptions - all of these have generated builders.

The implementation would be “straightforward” - in ThriftyCodeGenerator#buildStruct, add a separate code path for nobuilder types. Specifically, we’d need to suppress the call to builderFor and modify the generated adapter (created in adapterFor). The tricky part will be modifying GenerateReaderVisitor, which is the class that is responsible for generating deserialization code for each field of a struct/union/exception. It assumes that there is a builder involved, which would no longer be guaranteed - either we’ll need a variant of this visitor that doesn’t use builders, or this one should be rewritten to never use builders.

The latter approach would be simpler, and could potentially make generated code much more proguard-friendly.

I haven’t thought deeply about this, so it’s possible that I’ve missed an important edge-case here.

[benjamin-bader]

That’s an interesting question. There isn’t any way to strip out the Builder types; the generated adapter code uses them to implement deserialization.

I’d never thought about request/response types before, because Thrift itself makes no such distinction; it’s more of an application-specific label. It’s an interesting idea though, and one I could see being implemented, for example:

struct SearchResult {
  ...
} (thrifty.nobuilders = "true")

It would be a relatively big job, and I don’t have the time to implement it. I’d be happy to talk design and coach someone through a PR, though!