Currently the code generator has a map of string to string field that denotes the "annotations" for a field: https://github.com/apache/thrift/blob/90ea2e8398eda32da8be0b3514516e7ad932a869/compiler/cpp/src/thrift/parse/t_field.h#L109
It is made available to generators such as JSON (in https://github.com/apache/thrift/blob/90ea2e8398eda32da8be0b3514516e7ad932a869/compiler/cpp/src/thrift/generate/t_json_generator.cc#L267-L274) to allow (runtime) interpretation of such metadata.
In Java, similar mechanism exists to register field metadata (via https://github.com/apache/thrift/blob/90ea2e8398eda32da8be0b3514516e7ad932a869/compiler/cpp/src/thrift/generate/t_java_generator.cc#L2862-L2865 which calls `org.apache.thrift.meta_data.FieldMetaData#addStructMetaDataMap` method to register into a centralized places. Such metadata is useful, e.g. the microservice framework Ameria uses it (https://github.com/line/armeria/blob/5c2efebc7ba2350540d0554f530c173a49eb4c19/thrift0.13/src/main/java/com/linecorp/armeria/server/thrift/THttpService.java#L553-L554) to dynamically proxy requests.
However the existing field metadata only contain information about field id, type, and name, but it does not contain annotations. Adding annotations will be useful for situations e.g. (these are useful enablement at user side, make possible if annotation is included)
- some static metadata is useful at runtime for dynamic operations, e.g. like what `deprecated` means in the context of a field, adding `obfuscated` allows the user site to decide to obfuscate detailed information
- allows for more richer and more type specific validation and transformation logic, e.g. since we can only have string as field type, adding `date_format="YYYY-MM-DD"` allows the thrift struct to be interpreted as a local date and thus can automatically be converted to java.time.LocalDate
This should be a back-compatible change as the default behavior is not to include the annotation. A second constructor can be added to allow included annotation to exist and register.