Pass annotations through

[casidiablo]

I'd be cool if any annotations defined in the interface getter methods, and maybe even the interface itself, were propagated to the Value class. Something like https://github.com/google/FreeBuilder/pull/81 but for any annotation, not just @JsonDeserialize.

One of the use cases this would cover is AWS DynamoDb Object Mapper: it uses annotations to determine how to (de)serialize the properties as well as defining primary keys, etc.

[alicederyn]

In general it's not safe to propagate annotations like that. Why does AWS DynamoDb Object Mapper not look at the methods defined on your interface/abstract class to find annotations?

[casidiablo]

I guess they don't do it for simplicity.

Why isn't it safe? Whether to propagate the annotations or not should be a decision the developer takes. It could be optional and disabled by default.

[daniel-shuy]

I would like this for JPA entity classes as well, as the generated class needs to be annotated with @Entity. Extending the generated class will not work as well, since all superclasses need to be annotated with @MappedSuperclass.

[alicederyn]

An example of a class annotation that cannot be copied to subclasses is Guice's @ImplementedBy. Another example is @FreeBuilder itself. Can't find any open-source method annotations right now, but the idea is similar. We've proposed a couple such for possible @FreeBuilder extensions, e.g. a @Cached annotation that definitely shouldn't be copied to the subclass's method override.

The problem is that the semantics of whether annotations should be copied are decided by the annotation, not the class, so a simple "turn on/off copying of annotations to the generated class" doesn't work in complex cases.

I suggest the correct fix would be (for cases where the code using the annotations can't be fixed) (a) add an extension API to FreeBuilder to allow users to declare how specific annotations should be copied (or replaced with other annotations) on a case-by-case basis [so people could publish libraries marrying FreeBuilder and various libraries], (b) merge common instances back into FreeBuilder, so support is out-of-the-box. This is very low cost to users of FreeBuilder, as thanks to the way Java exposes compile-time information to us, we don't need an explicit dependency on these libraries in FreeBuilder, so they won't get unexpectedly pulled into downstream projects.