Allow `JsonNames` on classes

[ansman]

What is your use-case and why do you need this feature?
We have polymorphic type that maps to two labels when decoding so I'd need a way to indicate that a type has two type constants.

Describe the solution you'd like
I propose the @JsonNames annotation be allowed on classes which would be used in addition to @SerialName (today it can only be used for properties).

[pdvrieze]

Assuming that you want to use @JsonNames on classes as a form of type alias, if it is a polymorphic type, why do you not deserialize it as such? This is one of those features where the "start with -100 points" idea comes in. The problem is it adds complexity and runtime costs to all deserialization also when not used.

[sandwwraith]

You can use polymorphicDefaultDeserializer, which accepts a lambda with a class name parameter for that.

[ansman]

Assuming that you want to use @JsonNames on classes as a form of type alias, if it is a polymorphic type, why do you not deserialize it as such? This is one of those features where the "start with -100 points" idea comes in. The problem is it adds complexity and runtime costs to all deserialization also when not used.

This comment doesn't make sense to me for a few reasons:

• The same argument could be made for @JsonNames in general yet that exists
• The overhead would be negligible (an extra string constant and one more switch branch) and only applicable classes that use it and obviously when you use it the overhead would be worth it
• Who is saying I'm not deserializing it as a polymorphic type?

[ansman]

You can use polymorphicDefaultDeserializer, which accepts a lambda with a class name parameter for that.

Sure but that would force me to write the deserialization pretty much manually. The same argument could be made for @JsonNames on a property (just write your own serializer).

For context, we are migrating some classes that were using the default serial name for types (the class name) but would like to switch to explicit descriptors. To ease this migration it would have been great if I could simply annotate the classes with the old serial name.

I don't see a technical reason why it wouldn't be supported on classes, is there one?

[pdvrieze]

• The same argument could be made for @JsonNames in general yet that exists
• The overhead would be negligible (an extra string constant and one more switch branch) and only applicable classes that use it and obviously when you use it the overhead would be worth it
• Who is saying I'm not deserializing it as a polymorphic type?

The overhead would be that the format would need to be adjusted to look up the aliases and match them to the actual type. On second thought this could be done as fallback only (so there is little overhead when not used, as there is already error handling anyway)

If you are deserializing polymorphically then you could do subclassing instead of aliasing (and if the underlying types are not different why do they have different names in the first place?).

[ansman]

If you are deserializing polymorphically then you could do subclassing instead of aliasing (and if the underlying types are not different why do they have different names in the first place?).

This would be done to aid a migration from one serial name to another. Subclassing won't work if the leaf nodes are data classes.