Support Java 1.6

[zambien]

Description

Would it be acceptable to add Java 1.6 support to this project? I have created a fork at zambien/swagger-codegen which has most of the changes needed to do this (replace java.util.Objects and associated code/mustaches with google guava). I work in an environment which runs Java 6 servers and there is not an opportunity to upgrade them unfortunately.

Swagger-codegen version

master

Suggest a Fix

Please take a look at my fork and let me know if a pull request to include Java 1.6 support is acceptable.

[wing328]

What about running swagger generator via docker instead?

https://hub.docker.com/r/swaggerapi/swagger-generator/

[ePaul]

Just to make sure: Do you need Java 6 for running Codegen, or for running the generated code?
The latter certainly should be supported.

[fehguy]

I don't think going to java 6 makes sense. It's been EOL'd for a while now, and I don't want to constrain updates in the core code to not use java 7 features.

As @ePaul said, you can certainly use generated clients with java6 (for now).

[zambien]

Thanks for the clarifying questions and responses.

I'm trying to get a generated client to work in Java 6. The generated client code includes java.util.Objects, java.util.Objects.equals, and java.util.Objects.hash which are not in Java 6. I have tried playing around with targetCompatibility to no avail. Is there something I'm missing that will create a Java 6 set of compatible client Java classes?

The fork:

https://github.com/zambien/swagger-codegen

Replaces all of the java.util.Objects java code and mustache files with google guava as well as including guava where it is required.

[ePaul]

I guess for the generated Java files (i.e. the Mustache files) we can/should do that, I wouldn't do it for the generator code (i.e. CodegenModel and friends).

Maybe we can introduce an option for the equals/hashCode implementations, whether to use Java 8 or Guava, like we are doing for JodaTime vs. Java8 time?

[zambien]

I think that is an excellent idea. I was making changes as I was starting to understand the project which is why I didn't create a PR just yet.

[ashughes]

I'm running into this issue as well with Objects.equals() and Objects.hash(). In our case, I'm using the generated code on Android, so we're stuck with the Java 6 requirement unless we have minSdk 19.

The reason we use Java instead of Android for the codegen language, is we want to use retrofit2, which is not an option for the android generator (I'm not sure why). However, I just tried generating for Android and it did not use the Java 7 Objects.equals() and Objects.hash(). So, as mentioned above, it would be great to have an alternative option such as Guava, or even the explicit code that the Android codegen uses.

[wing328]

@ashughes if we provide an option to remove Objects.equals() and Objects.hash() in the Java API client, would that meet your requirement?

[ashughes]

@wing328 I think so. We just started using Swagger, so we haven't used it extensively yet, but that's the only Android compatibility issue we've run into so far.

[cbornet]

We should probably have a "javaVersion" option that would provide some defaults:

• jdk6 : no java.util.Object, threetenbp as default date lib
• jdk7 : threetenbp as default date lib
• jdk8 : java.time as default date lib

[ashughes]

I agree with @cbornet. However, on Android the default date lib should be ThreeTenABP. Maybe there could be an "androidVersion" or "androidMinSdk" option with defaults:

• 1 : no java.util.Objects, ThreeTenABP as default date lib
• 19 : ThreeTenABP as default date lib