AutoValue.java RentionPolicy(RetentionPolicy.SOURCE)

[williamwebb]

If there is no downside to increasing the retention level it would be extremely helpful to have this annotation retained at the Runtime for Deserialization purposes.

As shown here, currently to achieve deserialization an additional annotation is required. Which while this works requires users to know to use this annotation. If AutoValue.java were retained at runtime there would be a concrete relationship that could be used and enforced by the AutoValue annotation processor.

[eamonnmcmanus]

I'm not sure this is sufficiently strong motivation. The retention is SOURCE because this is an implementation detail. Clients of an AutoValue class should neither know nor care that it is one.

Assigning to @kevinb9n for a second opinion.

[JakeWharton]

There's also https://github.com/rharter/auto-value-gson/ now which uses the built-in extension mechanism to achieve the same effect as my Gist without reflection.

[williamwebb]

@JakeWharton only reasoning for not going with that option is it again requires the uses of AutoValue to know to add the static method to return the TypeAdapter. For something that would ideally be transparent.

[kevinb9n]

I think that extension or another like it is the right place to work this out.

Sometimes people disagree with Éamonn's statement, "Clients of an AutoValue class should neither know nor care that it is one." But the difficulty with disagreeing with it is that it's the founding principle of AutoValue. It's the exact notion that made our idea sufficiently differentiated from the heap of other existing solutions to be worth building.

The annotation is not even Documented, let alone visible at runtime.

[williamwebb]

👍