Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enum naming strategy should allow different naming conventions used in source code #4675

Open
hajdamak opened this issue Aug 19, 2024 · 6 comments
Labels
pr-welcome Issue for which progress most likely if someone submits a Pull Request

Comments

@hajdamak
Copy link

hajdamak commented Aug 19, 2024

Is your feature request related to a problem? Please describe.

Currently CamelCaseStrategy in EnumNamingStrategies assumes that enum entires in source code are named using UPPER_SNAKE_CASE convention, for example: enum Size { VERY_BIG }.
However in Kotlin quite often UpperCamelCase is used, for example enum class Size { VeryBig }. CamelCaseStrategy in EnumNamingStrategies does not work with such a naming.

Describe the solution you'd like

Strategies in EnumNamingStrategies should work with enum entries written in code using different naming conventions like UpperCamelCase .

Usage example

No response

Additional context

No response

@hajdamak hajdamak added the to-evaluate Issue that has been received but not yet evaluated label Aug 19, 2024
@hajdamak hajdamak changed the title Enum naming strategy should allow different naming conventions used in code Enum naming strategy should allow different naming conventions used in source code Aug 19, 2024
@cowtowncoder cowtowncoder added pr-welcome Issue for which progress most likely if someone submits a Pull Request and removed to-evaluate Issue that has been received but not yet evaluated labels Aug 21, 2024
@cowtowncoder
Copy link
Member

I am not 100% sure if this can be done reliably, but if so, sounds like a reasonable idea.

@JooHyukKim
Copy link
Member

I believe naming conventions wrt Enum is somewhat controversial.
Here is reference to discussion in Kotlin.

As far as I know it is conventional to use

  • UPPER_SNAKE_CASE in Java
  • 50/50 debate on UPPER_SNAKE_CASE vs PascalCase in Kotlin

So it might be safer off to provide extension points instead of declaring what Enum naming would be.
But as @cowtowncoder mentioned, idk how it could be reliable, technically, since now we would have naming strategies two-ways, in-and-out.

@yihtserns
Copy link
Contributor

yihtserns commented Aug 28, 2024

Sounds like something that https://github.com/FasterXML/jackson-module-kotlin can/should(?) support out-of-the-box:

internal class KotlinAnnotationIntrospector(...) {
   ...
   override fun findEnumNamingStrategy(config: MapperConfig<*>, ac: AnnotatedClass): Any? {
      return PascalCaseOrCamelCaseStrategy()
   }
}

@cowtowncoder
Copy link
Member

@yihtserns Perhaps, although if so, should only apply to Kotlin Enum types? And be configurable to allow disabling such logic.

@yihtserns
Copy link
Contributor

yihtserns commented Aug 28, 2024

...should only apply to Kotlin Enum types?

I think so far nobody from Java side has ever requested such thing, right? The reason this issue was created is because only Kotlin side has such "double standard". 🤐

EDIT: Oh you mean findEnumNamingStrategy should only return PascalCaseOrCamelCaseStrategy if the AnnotatedClass method arg is an enum class generated from Kotlin source code.
UPDATE: E.g.:

internal class KotlinAnnotationIntrospector(...) {
   ...
   override fun findEnumNamingStrategy(config: MapperConfig<*>, ac: AnnotatedClass): Any? {
      if (ac.annotated.isKotlinClass()) {
         return PascalCaseOrCamelCaseStrategy()
      }
      return null
   }
}

@cowtowncoder
Copy link
Member

Right, if there are reliable means to detect that information. Similar to how Kotlin special sauce avoided (I think?) for POJOs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pr-welcome Issue for which progress most likely if someone submits a Pull Request
Projects
None yet
Development

No branches or pull requests

4 participants