@sandwwraith, have I a chance to get review and merge this fix?
I can't continue my work on the config4k library without it. 😞

I'm a little bit hesitant to add this annotaiton for Hocon, since we do not have a Json equivalent; if same problem arises in Json (it is there for JsonNamingStrategy, for example), maybe we would need a better generalized solution.

What are benefits of having this annotation instead of just disabling "useHoconNamingConvention"? Or maybe we need a specific annotation, e.g.,@DisableHoconConvention instead? I imagine it can be quite confusing if I had@HoconName("fooBar") @SerialName("fooBar") on the same property

What are benefits of having this annotation instead of just disabling "useHoconNamingConvention"?

I don't want to disable this naming convention, because 99% of the fields follow this convention. However, we also need the ability to set a serial name manually from time to time. 🤷‍♂️

Or maybe we need a specific annotation, e.g.,@DisableHoconConvention instead?

Yes, potentially this solves the problem by using two annotations per field, but it doesn't look so good either. 🤔

@Serializabledataclass (  @DisableHoconConvention  @SerialName("unConventionField")val unConventionField:String)

I imagine it can be quite confusing if I had@HoconName("fooBar") @SerialName("fooBar") on the same property

Do you mean the situation where one type can be serialized in multiple formats?

since we do not have a Json equivalent

We have the@JsonNames annotation as an alternative name for fields. Perhaps using alternative names instead of overriding the serial name with a special annotation would be a more preferable approach for you. 🤔

I have looked the options for not having per-format naming annotations. I am not sure that those annotations can be avoided if you want to be able to use the same serializers for different formats (with potentially different names). Even if a functional strategy is used, it would often have to resort to either a built-in translation table or custom annotations.

@ihostage

Do you mean the situation where one type can be serialized in multiple formats?
Yes. In case I have a class serialized both to Hocon and Json, it is possible to end up in this situation. Although it can indeed be quite rare.

We have the @JsonNames annotation as an alternative name for fields

It works for deserialization alone.@HoconName though affects encoding as well. If you think that this problem is specific to deserialization, yes,@JsonNames analogue would be preferable.