Openapi-generator: [Java] new option: Throw an exception for invalid enum values instead of using null

[jmini]

I have a similar problem than the one reported in https://github.com/swagger-api/swagger-codegen/issues/5950

When working with enum in a java server, if the enum value sent by the client is unknown, after deserialization, the value is set to null.

This might be useful in some cases (the OpenAPI Spec does not always contains all the possible values) but is not the behavior expected in most of the cases.

---

After having looked at the thread https://github.com/swagger-api/swagger-codegen/issues/5950
I propose to add a new option: useNullForUnknownEnumValue:

• true (current behavior 3.1.x)
• false

In my opinion (and as other participants in the original thread) starting with 3.2.0 the new default should be false.

With useNullForUnknownEnumValue == true:

https://github.com/OpenAPITools/openapi-generator/blob/af3ca293e4ff3defcbfd4a32b82f7d3229a29d48/samples/server/petstore/jaxrs/jersey2/src/gen/java/org/openapitools/model/EnumTest.java#L52-L61

With useNullForUnknownEnumValue == false:

   @JsonCreator 
   public static EnumStringEnum fromValue(String text) { 
     for (EnumStringEnum b : EnumStringEnum.values()) { 
       if (String.valueOf(b.value).equals(text)) { 
         return b; 
       } 
     } 
     throw new IllegalArgumentException("Unexpected value '" + text + "'");
   } 
} 

---

In the thread there is also a discussion about removing fromValue and the @JsonCreator to let Jackson handling deserialisation.

This is not possible in my opinion:

• There are cases where the Java enum name is not the enum value. (Lowercase/uppercase, values with spaces are allowed in OAS3, …)
• The type of the value is not always a string.

---

cc: @TehBakker, @slarti-b, @wing328, @cbornet

Java Technical Committee: @bbdouglas (2017/07) @JFCote (2017/08) @sreeshas (2017/08) @jfiala (2017/08) @lukoyanov (2017/09) @cbornet (2017/09) @jeff9finger (2018/01)

[slarti-b]

Well, thanks for the ping - I did say I'd look into the swagger issue and still intend to, but haven't had time. And I hadn't even noticed the fork! i was wondering when a new swagger codegen release would come along.:)

I'll have to consider which to use going forward - I'm inclined towards this but need to discuss internally. in the meantime how close the codebases? Are you still integrating changes from swagger or vice versa? If I wanted to fix in both, which is easier to start with, in terms of then being able to merge into the other?

[jmini]

This project is a fork of swagger-api/swagger-codegen due to some disagreements with:

• some fundamental choices made for Swagger-Codegen-v3.
• the governance of the project in general.

Swagger-Codegen-v3 and OpenAPI-Generator are both based on Swagger-Codegen-v2, but they now live separately. You can read more in the Q&A.

I would say that this project is closer to swagger-codegen-v2 than swagger-codegen-v3 from swagger-codegen-v2.

If you wants to fix both, I think that you will need to do the work twice (even if the code base are close)

If you are migrating from swagger-codegen-v2 to openapi-generator, this migration guide might be useful.

[jmini]

PR for this issue: #633

[cbornet]

:+1: for throwing exception being the default