[Java][Jersey2] Java6 compatibility broken in ApiClient using diamond operator without generic type inference

[jcohen-stingray]

Description

ApiClient.mustache template for method invokeApi() uses return statements that do not conform to java 6 compatibility. Return statements should include generic type in method definition. Every other class generated with the java-jersey2 generator is java6 compatible with regards to diamond operators.

C:\dev\...\clientjava6\ApiClient.java:698: error: diamond operator is not supported in -source 1.6
        return new ApiResponse<>(statusCode, responseHeaders);
                               ^
  (use -source 7 or higher to enable diamond operator)
1 error

openapi-generator version

3.0.3

OpenAPI gradle task specification

openApiGenerate {
    inputSpec = swaggerInput.path
    outputDir = swaggerOutputDir.path
    generatorName = 'java'
    library = 'jersey2'
    invokerPackage = "com.stingray." + root_project_without_hyphen + ".$project.name".replaceAll(~/-/, "")
    modelPackage = "com.stingray." + root_project_without_hyphen + ".$project.name".replaceAll(~/-/, "") + ".model"
    apiPackage = "com.stingray." + root_project_without_hyphen + ".$project.name".replaceAll(~/-/, "") + ".api"
    generateApiTests = true
    generateApiDocumentation = false
    generateModelTests = true
    generateModelDocumentation = false
    additionalProperties = [
        'supportJava6' : 'true',
        'dateLibrary' : 'threetenbp',
        'sourceFolder'  : 'src/generated/java/',
    ]
}

Steps to reproduce

1. Using the gradle plugin and any valid specification swagger yaml file, run the openApiGenerate task to generate a java client.
2. In the build.gradle file, set the compileJava settings to java 1.6:

compileJava {
    sourceCompatibility = 1.6
    targetCompatibility = 1.6
}

3. Run gradle build to see the compilation error.

Suggest a fix/enhancement

The file ApiClient.mustache, add generic type to the 3 return statements of the method invokeApi():

if (response.getStatus() == Status.NO_CONTENT.getStatusCode()) {
        return new ApiResponse<T>(statusCode, responseHeaders);
      } else if (response.getStatusInfo().getFamily() == Status.Family.SUCCESSFUL) {
        if (returnType == null)
          return new ApiResponse<T>(statusCode, responseHeaders);
        else
          return new ApiResponse<T>(statusCode, responseHeaders, deserialize(response, returnType));

Lines 712 through 717.

[jmini]

Thank you a lot for this issue! I will try to look into it.

[jmini]

I have proposed a PR: #560

[jason-cohen]

Nice. Much more encompassing than my suggested fix. I'll retract my PR in light of yours. Thanks!

[jmini]

@jason-cohen I am really sorry not having seen that you were working on this too.
If you have tested my PR, please leave a comment there, so that we know it works for you.

[wing328]

@jcohen-stingray the PR has been merged. Let us know if you still see issues.

FYI. I'm preparing tests to better catch the issue moving forward.

[wing328]

UPDATE: I've filed #568 with a travis.yml file to catch the issue moving forward.