Openapi-generator: Refactor AbstractJavaCodegen and inheriting generators to allow use of modern Swagger annotations

[InfoSec812]

Description

In #2972, #6108, #5478, and many others there are complaints about old libraries/annotations being used in various Java generators. As a user of OpenAPI Generator who works in a number of Java toolkits/frameworks, I would like to see the AbstractJavaCodegen and all child generators updated to allow the use of the latest annotations and features of OpenAPI.

openapi-generator version

v5.0.0 Beta

Related issues/PRs

2972, #6108, #5478

Suggest a fix/enhancement

I will be preparing a fork/branch which I will link in the comments below.

[InfoSec812]

The work I am doing will be track in this branch:

https://github.com/InfoSec812/openapi-generator/tree/Issue_7112-_-Refactor_AbstractJavaCodegen_and_inheritors

Design Goals:

1. MUST not break backward compatibility
2. SHOULD allow for more flexibility in choosing supporting libraries
   
   
   
   • Perhaps allowing variaous x- extensions to the API Spec will be a reasonable means
   
   
3. MUST allow for use of annotations which generate OpenAPI v3 output
4. MUST work with inheriting generators (or update them without breaking backward compatibility)
   
   
   
   • Spring/SpringBoot
   
   
   • JAX-RS
   
   
   • Vert.x
   
   
   • CXF
   
   
   • Play Framework
   
   
   • MSF4J
   
   
   • Jersey
   
   
   • Java Client
   
   

[InfoSec812]

To start, I think that adding a non-functional (for now) option in AbstractJavaCodegen which says something like preferOpenAPIv3 and then proceeding to update each set of templates from there makes sense. Any thoughts @macjohnny?

This would allow the default to continue using the existing templates/functionality and have no impact on backward compatibility. As the community goes through and adds support to the inheriting codegen implementations we could use that option as it becomes available.

[macjohnny]

@InfoSec812 Sounds good