[REQ] [Java] Configurable collections framework (like Vavr)

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

The Java/Spring/... generated models are using the Java collections from java.util like java.util.List or java.util.Map. It would be very nice to have a way to configure the generator to use another collections library which provides enhanced functionality.

Vavr is a Functional Programming library for Java which provides rich functional data structures/collections and functional idioms for Java. This is just an example, but ideally it could be configured to use any collections library (although I am really interested in Vavr).

Vavr also has a vavr-jackson module which allows to serialize/deserialize Vavr types using Jackson.

This provides a complete toolset to replace Java collections for your API as Vavr ones offer richer functionality.

The problem with Java Optional

(This is a side-problem, but directly related to the feature request)

When using the generator for Spring/spring-cloud (or just using a Feign client) in your client application, the already existent <useOptional>true</useOptional> configOption seems not to work. If I recall correctly this appeared to be because Java's Optional did not implement Serializable deliberately. And as per some trial I ran time ago, using this setting breaks the Feign.

useOptional | Use Optional container for optional parameters

To put it clear, the generated code is something like the following:

@RequestMapping(value = "/some-endpoint",
        produces = { "application/json" }, 
        consumes = { "application/json" },
        method = RequestMethod.GET)
ResponseEntity<MyRespDto> someEndpoint(@Valid @RequestParam(value = "someQueryParam") Optional<String> someQueryParam);

or

@RequestMapping(value = "/some-endpoint",
        produces = { "application/json" }, 
        consumes = { "application/json" },
        method = RequestMethod.GET)
ResponseEntity<MyRespDto> someEndpoint(@Valid @RequestParam(value = "someQueryParam") Optional<SomeEnum> someQueryParam);

When using the above setup, Feign client complains about the Optional not being serializable and does not work. Vavr counterpart Option do implement Serializable on contrary (apart of other benefits and being a real Monad).

Describe the solution you'd like

Ideas on configuration

I can think in a way to specify a configuration to map the collection types generated from the API definition YAML to the target classes like the following:

(the following is just an example to express the intent)

<configOptions>
    <listType>io.vavr.collection.List</listType>
    <mapType>io.vavr.collection.Map</mapType>
    <optionalType>io.vavr.control.Option</optionalType>
</configOptions>

The generated code should include the corresponding types {List|Map|Option} and the required imports (even if had different names like com.example.XList).

Describe alternatives you've considered

I know I could modify the Moustache templates and keep my own fork with the changed templates, but I think this could be a general use-case that would be great that was configurable. As we are doing API-First approach, everything turns around the generated classes, so allowing to configure collection library for the generated DTO models would be very useful.

No specific file or test is named; start by tracing the Java generator's configOptions and the Moustache templates mentioned in the issue. Done means collection and optional types can be configured, generated imports support differing type names, and the Spring or Feign Optional case is addressed.