Add `@EnumNaming`, `EnumNamingStrategy` to allow use of naming strategies for Enums

[cowtowncoder]

As things are, the only way to change representation of Enum values (which defaults to using Enum.name()) is to use either "use toString()" or explicit @JsonProperty overrides.
But it appears that there is usage where there is naming convention in use, similar to how @JsonNaming works mapping POJO fields to external JSON property names.

One possibility might be to try to directly support use of @JsonNaming on Enum classes.
This may or may not be practical, considering underlying PropertyNamingStrategy is tied to accessors (Field, Method) that POJOs expose -- but bigger issue may be that this would be two-dimensional mapping as unlike POJO property names that use Bean naming ([lower] camel case), Enum names themselves may use one convention, and external names another one.
As such it may be necessary to either come up with new abstraction(s), or maybe just alternate PropertyNamingStrategy implementations.

NOTE: implementation adds

• @EnumNaming annotation
• with EnumNamingStrategy (for strategy implementations)
• EnumNamingStrategies container for a set of out-of-the-box EnumNamingStrategy implementations
  • For 2.15, only CamelCaseStrategy added -- replaced in 2.19 with LowerCamelCaseStrategy

Jackson 2.19 will further add a large set of new strategy implementations.

[jomatt]

What's the status on this one?

I really like the proposal from @cowtowncoder. Usually, you want to decouple the internal enum values from their external JSON representation so that you can refactor and change enum values without directly impacting the clients of your application. In general, this doesn't only apply to enums but to all kinds of abstraction, so it would definitely make sense to have a possibility to configure this.

The MapperFeature.ACCEPT_CASE_INSENSITIVE_ENUMS property already helps with this, but does not work in case you have multi-word enum values, e.g. MATCH_FILTER, which should be represented as MatchFilter or matchFilter depending on your naming convention

[cowtowncoder]

Hi @jomatt! I haven't had time to get this any further unfortunately. It is highly-voted for so I hope someone with time and interest might want to tackle it for 2.15. As usual I may not have time to implement this, but I make time to help others get their contributions in, if any.

[JooHyukKim]

Hi @jomatt! I haven't had time to get this any further unfortunately. It is highly-voted for so I hope someone with time and interest might want to tackle it for 2.15. As usual I may not have time to implement this, but I make time to help others get their contributions in, if any.

can we discuss a latest approach?

At first I thought of adding more ‘EnumFeture’ but I would say no because there will probably be per-enum-class naming strategy.

And also -1 from me on direct support from ‘@JsonNaming’ because as @cowtowncoder mentions above, there will be two dimensional mapping.

So my suggestion is, extending JsonNaming, something like ‘@JsonEnumFeature’ ?

[cowtowncoder]

Cannot be "feature" as those are on/off things, so would be something like @JsonEnumNaming I think. But there's still the question of how to deal with PropertyNamingStrategys binding to POJO accessors.

[JooHyukKim]

Cannot be "feature" as those are on/off things, so would be something like @JsonEnumNaming I think. But there's still the question of how to deal with PropertyNamingStrategys binding to POJO accessors.

I guess if target enum class is annotated with @JsonEnumNaming , override all other naming strategies?

[JooHyukKim]

Plus we should also consider Enum used as json key or used as json value