[BUG] [JAVA] Generator incorrectly altering enum values

[daoudsleiman]

Bug Report Checklist

• [x] Have you provided a full/minimal spec to reproduce the issue?
• [x] Have you validated the input using an OpenAPI validator (example)?
• [x] Have you tested with the latest master to confirm the issue still exists?
• [x] Have you searched for related issues/PRs?
• [x] What's the actual output vs expected output?
• [ ] [Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

There are 2 places where i observed this bug. One of which was with an array of camelCase values being changed to snake_case and the other with an enum value that contains a number.

S4A -> S4_A but expected S4A or
middleAgeFemale -> MIDDLE_AGE_FEMALE but expected MIDDLEAGEFEMALE

openapi-generator version

version >7.4.0. This issue does not occur in 7.4.0

OpenAPI declaration file content or url

    Schema1
      type: string
      enum:
        - S4A
        - ENUM_VALUE_ONE
        - ENUM_VALUE_TWO
        - ENUM_VALUE_THREE

This produces enum values S4_A, ENUM_VALUE_ONE, ENUM_VALUE_TWO, ENUM_VALUE_THREE or

    Schema1:
      type: string
      example: "middleAgeFemale"
      enum:
        - "middleAgeFemale"
        - "middleAgeMale"
        - "seniorFemale"
        - "seniorMale"
        - "teenageBoy"
        - "teenageGirl"
        - "youngAdultFemale"
        - "youngAdultMale"

This produces enum values MIDDLE_AGE_FEMALE, MIDDLE_AGE_MALE ...

Generation Details

Java OpenAPI Generator in Spring Boot application

Steps to reproduce

1. Create a schema with an enum value of type string.
2. Include a number in one of the enum values or create camelCase values only
3. run the code generator
4. results for the number will look like this: S4A -> S4_A but expected S4A or
   middleAgeFemale -> MIDDLE_AGE_FEMALE but expected MIDDLEAGEFEMALE

Related issues/PRs

Suggest a fix

My work around for this was to use x-enum-varnames to manually fix these 2 cases

[jpfinne]

The change was done in #18594. The description in the PR and in #4837 seems to indicate that the underscore is a better choice to follow the java naming convention.

Unfortunately this was done in a minor version without even a mention in the release note.

A really poor workaround is specified in the PR (enumNameMappings) I like your option better, but it still requires a lot of effort

[daoudsleiman]

@jpfinne Thanks for adding that context. Do you know why the other enum string i mentioned is also causing issues? S4A -> S4_A but expected S4A. If i change the enum to SFA, I get the intended result of SFA.

[jpfinne]

Good question!

It uses a method in StringUtils:

   /**
     * Underscore the given word.
     * Copied from Twitter elephant bird
     * https://github.com/twitter/elephant-bird/blob/master/core/src/main/java/com/twitter/elephantbird/util/Strings.java
     *
     * @param word The word
     * @return The underscored version of the word
     */
    public static String underscore(final String word) {

[nedsko]

I'm having the same problem with enums containing numbers. In my case it's B2B -> B2_B.

[blutorange]

I also noticed this. I agree that the naming convention is more suitable for Java, but this change is in particular an issue if you are already using code that depends on a generated client. When you update the generator plugin, you now need to change all the code that depends on that client (assuming you even have access to that code).