Update to JDK11

[wing328]

• Update to JDK11, fix tests

cc @OpenAPITools/generator-core-team

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package 
  ./bin/generate-samples.sh
  ./bin/utils/export_docs_generators.sh
  

  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*.
  For Windows users, please run the script in Git BASH.
• In case you are adding a new generator, run the following additional script :

  ./bin/utils/ensure-up-to-date
  

  Commit all changed files.
• File the PR against the correct branch: master (6.3.0) (minor release - breaking changes with fallbacks), 7.0.x (breaking changes without fallbacks)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

[agilob]

Yes, looks good to me.

[wing328]

@agilob btw, I included the suggested fix in jknack/handlebars.java#917 but still got the same error. I ended up updating the template to fix the issue instead.

[wing328]

FYI. Tested locally in a Windows laptop (JDK11) and the project built without issues.

[agilob]

👏

[davidmoten]

I think the move was premature simply because of how many companies still rely on Java 8. Was there any public discussion of this? See https://newrelic.com/resources/report/2022-state-of-java-ecosystem, with this pic:

I bumped into this problem when I upgraded openapi-generator-maven-plugin to 7.0.0 and tried to build my JDK 8 project.

[agilob]

The survey is about backend software running in a cloud, which has nothing to do with cli applications executed rarely, locally, all self-contained, I'm actually surprised this PR hasn't proposed moving to 17 already. New 21 will be released next month.

[davidmoten]

ok, ta. I'll have another hunt around for stats, see if I can get a clearer picture. My company has a lot of code at 8 that is a very large job to upgrade to later JDKs and a small amount at JDK 17. I suspect a similar picture across the world but I'll check.

[davidmoten]

Hmm, I can't find much more data than this but given that

• the survey is indicative of large usage still of Java 8
• OpenJDK 8 is supported till Nov 2026

Why throw away compatibility for a very large number of java users?

[wing328]

OpenJDK 8 is supported till Nov 2026

According to https://endoflife.date/java, OpenJDK8 support ends on 31 Mar 2022.

Where did you get the info it's supported till Nov 2026?

Why throw away compatibility for a very large number of java users?

We didn't intend to make the new version not compatible with a particular version of JDK. According to https://endoflife.date/java, OpenJDK8 (which was released 9 years ago) has reached EOL and that's why we moved on to JDK11 which is still supported.

Similar to upgrading this project from JDK7 to JDK8 a while ago, we understand that there are users who are still using old version of the JDK. One way is to use Docker instead if the users cannot upgrade JDK7 or whatever version that's reached EOL to newer versions for whatever reasons, or the user can choose to stick with OpenAPI Generator v6.6.0 for the time being (or customize it to meet their requirement using JDK8 but not something we recommend)

[davidmoten]

For example, https://adoptium.net/support/. RedHat, Amazon Corretto have similar statements (2026):

[davidmoten]

https://javaalmanac.io/jdk/8/

[wing328]

For example, https://adoptium.net/support/. RedHat, Amazon Corretto have similar statements (2026):

Thanks for sharing that the Adoptium Working Group and some other companies are willing to support JDK8 till 2026 (and glad that they got the funding to do so).

Would you or your company willing to sponsor this project to support JDK8?

(And according to https://www.reddit.com/r/java/comments/ssf228/clarification_of_openjdk_8_end_of_life/, Oracle is willing to support JDK8 till 2030 which is not a bad thing but clearly they've the freedom to do so but that doesn't mean every Java open-source projects in this planet need to support JDK8 till 2030.)

[davidmoten]

Would you or your company willing to sponsor this project to support JDK8?

Good question. I work for the Australian Government, I have no idea what hoops I have to jump through to sponsor you but I can ask. In the meantime can you consider reverting to JDK 8 for the build of your components before people start having fun with new JDK features? I frankly think those new features will be of pretty minor benefit given what openapi-generator project does.

[wing328]

@davidmoten thanks for asking but I would foresee it would take a while to get an answer. Why not use Docker instead if you cannot upgrade the stack to JDK11 or newer versions?

For your use cases, are you using a customized version of OpenAPI Generator to meet your unique requirements?

[davidmoten]

Will generated code require JDK 11? This will require a lot of work from us to adapt to (and we won't have the opportunity for a long while because of other priorities). Docker definitely not an option from a runtime perspective because our target OS is Solaris. We cannot move to > JDK8 till we migrate our large codebase (about 200 maven modules) to run on Linux. I'm talking Search and Rescue for Australian Government so there is lots to navigate before we undertake these changes.

Does 6.6.0 do the job for us? No, unfortunately we had to patch generated code heavily to get something that works. Consequently, for future OpenAPI-based tasks would be nice to pick up your most recent changes and be faced with fewer fixups.

In terms of our build infrastructure, requiring Docker would be painful. Vanilla Maven build pipelines have to be enhanced with this extra complexity, and some CI pipelines like Azure Devops may not allow us to do this for a Maven build (?). I'd still argue this is needless pain when the benefit to the openapi-generator project is questionable in terms of using later JDKs.

[wing328]

Will generated code require JDK 11?

Depends on the generators. Spring generator only support JDK17, which is required by the latest stable version of the Spring framework.

Java client (e.g. okhttp-gson, jersey2) generator still works with JDK8 while the native http library only supports JDK11, which is the minimal required.

Other option you can consider is to fork v6.6.0 and maintain it forward since you need to heavily customize the output anyway.