Approach for centralizing unknown enum handling

[gcatanese]

Approach for centralizing unknown enum handling

The handling of enums can be improved by centralizing the fromValue logic.

1. New EnumUtils utility (hand-written, non-generated)

src/main/java/com/adyen/util/EnumUtils.java

public final class EnumUtils {
    private static final Logger LOG = Logger.getLogger(EnumUtils.class.getName());

    private EnumUtils() {}

    public static <T extends Enum<T>> T fromValue(
            Class<T> enumClass, String value, Function<T, String> getValue) {
        for (T b : enumClass.getEnumConstants()) {
            if (getValue.apply(b).equals(value)) return b;
        }
        LOG.warning(String.format("%s: unexpected enum value '%s' - Supported values are %s",
            enumClass.getSimpleName(), value, Arrays.toString(enumClass.getEnumConstants())));
        return null;
    }
}

2. Template changes (modelEnum.mustache + modelInnerEnum.mustache)

Gated behind a useEnumUtils flag — same pattern as useReflectionEqualsHashCode, handleNullableProperties, and useNullForUnknownEnumValue already in the templates.

Imports — drop Logger when flag is on:

{{^useEnumUtils}}
import java.util.logging.Logger;
{{/useEnumUtils}}

Enum body — drop the LOG field when flag is on:

{{^useEnumUtils}}
  private static final Logger LOG = Logger.getLogger({{{datatypeWithEnum}}}.class.getName());
{{/useEnumUtils}}

fromValue — delegate to the utility:

  public static {{{datatypeWithEnum}}} fromValue({{{dataType}}} value) {
{{#useEnumUtils}}
    return com.adyen.util.EnumUtils.fromValue(
        {{{datatypeWithEnum}}}.class, value, {{{datatypeWithEnum}}}::getValue);
{{/useEnumUtils}}
{{^useEnumUtils}}
    for ({{{datatypeWithEnum}}} b : {{{datatypeWithEnum}}}.values()) {
      if (b.value.equals(value)) return b;
    }
    LOG.warning(String.format(
        "{{{datatypeWithEnum}}}: unexpected enum value '%s' - Supported values are %s",
        value, Arrays.toString({{{datatypeWithEnum}}}.values())));
    return null;
{{/useEnumUtils}}
  }

3. Scope — TAPI-only vs global

Both options are feasible:

• TAPI-only: Set useEnumUtils: true only in the TAPI config in adyen-sdk-automation. Safe and scoped to this PR, but leaves an inconsistency: TAPI enums use EnumUtils, all other services keep the per-enum Logger.
• Global (recommended): Set the flag across all service configs in adyen-sdk-automation, re-generate all services. Eliminates Logger from every generated enum consistently — which seems to be the intent of the original suggestion.

TAPI-only is a one-liner per config file in the automation repo and easy to do now; globally applying it later is equally straightforward since it's just a flag flip.

---

Also: the String.format() suggestion applies to the fallback (non-useEnumUtils) path in the template as well — worth fixing there too regardless of which direction we go.

Originally posted by @thomasc-adyen in #1906 (comment)

[Vinu2111]

Hi @gcatanese, I have a merged PR in this repo (#1952) and would like to work on this.
After reading through PR #1906 and the design @thomasc-adyen outlined, I believe the work that lives in this public repo is:

Create src/main/java/com/adyen/util/EnumUtils.java the hand-written utility with the generic fromValue logic Update templates-v7/libraries/jersey3/modelEnum.mustache and modelInnerEnum.mustache gating the Logger import, LOG field, and fromValue body behind the useEnumUtils flag, following the same pattern as useReflectionEqualsHashCode Add a unit test for EnumUtils

The flag activation in adyen-sdk-automation configs (to actually trigger re-generation) would remain with your team since that repo is private.
Does this scope make sense? Happy to put up a PR if you confirm this is the right split.

[Vinu2111]

Hi @gcatanese, following up on my earlier comment. While waiting I went ahead and drafted EnumUtils.java + the template changes locally to pressure-test the design, and found two things worth confirming before I open a PR:

Neither modelEnum.mustache nor modelInnerEnum.mustache actually contains import java.util.logging.Logger; directly it's inherited from a parent template. So I can't gate that import as described; I'd fully-qualify com.adyen.util.EnumUtils.fromValue(...) in the call instead, which also sidesteps inner-class import restrictions for modelInnerEnum.mustache.
{{{dataType}}} in these templates isn't always String it can be Integer/Float/Double too, and String enums support useEnumCaseInsensitive. Should EnumUtils.fromValue stay String-only (templates do String.valueOf(value) before calling in), or would you rather it take a generic value type so case-insensitive/non-String enums route through it as well?

Have the utility, a test file matching the existing com.adyen.util conventions, and both template diffs ready locally, happy to open the PR as soon as you confirm the direction on #2.