Tatu Saloranta et al., *Pull Request Description* Use a TCK tested OpenJDK build distribution (*latest*) along with *fixed* (major) versions for additional test coverage.
My pull request for the GH workflow file is located here: .github/workflows/main.yml <https://github.com/carldea/jackson-databind#diff-7829468e86c1cc5d5133195b5cb48e1ff6c75e3e9203777f6b2e379d9e4882b3> *Introduction* Hello, I'm a big fan and user of the Jackson APIs/libraries for marshalling/unmarshalling POJOs on many projects in the past, present and future. I recently created a pull request relating to CI/CD workflows using GitHub Action's *setup-java@v2 *to build and test artifacts using 'zulu' as a JDK distribution instead of 'adopt' and its successor 'temurin'*. * I wrote a detailed article explaining the (how/why) a GitHub project should make the switch: Foojay.io GitHub Actions with Java <https://foojay.io/today/github-actions-with-java-part-2/> Below are some of the highlights and recommendations from the article: *AdoptOpenJDK* is discontinued For those not familiar with the recent announcement from AdoptOpenJDK. AdoptOpenJDK distributions will be discontinued on *July 2021* (https://adoptopenjdk.net). To make a long story short, they rebranded as Adoptium and moved under the Eclipse Foundation (build name: Temurin). When choosing OpenJDK distribution in GH action you have two choices: 'zulu' or 'temurin'. *Using Fixed (major) JDK Versions* This allows better test coverage for users of your library. For instance, customers or production environments will have fixed versions of a *JRE/JDK* and getting the latest build distribution could/has broken things in production. ie: build/test succesfully on the latest JDK 11, and production is running library on JDK 11.0.3 fails. Here's an example of using fixed (major) JDK versions in GH Actions. HdrHistogram <https://github.com/HdrHistogram/HdrHistogram/blob/master/.github/workflows/maven.yml> *GitHub workflow PR changes:* The current YAML workflow uses the latest LTS JDK builds as shown below: *java_version: ['8', '11']* The proposed YAML workflow uses both fixed(major) versions and the latest: * java_version: ['8.0.192', '8', '11.0.3', '11']* Using fixed (major) versions are often good practice whenever a *build/test* triggers (push/pull Git events) you can help determine whether a build failed because of the latest JDK build or was it because of something in your code that caused the issue. If the *latest JDK* (such as JDK 11) had *failed* (red) its build process and the fixed (major) version (such as 11.0.3) *passes* you'll know immediately that it was *not your code* that caused the issue, but rather the *latest JDK build*. If this PR is accepted, we could also add JDK versions '17.0.1' and '17' because of it being an *LTS* release. Also, for the new JDK '18-ea'. Azul's zulu build of the OpenJDK has the following benefits: - Java TCK tested - Zulu has archived fixed (major) releases - JDK Build releases prior to Sept. 2021 - Zulu has the latest version of the OpenJDK JDK between 6 - 18ea Feel free to reach out to me here or on GitHub to let me know what you think. :-) Thank you, Carl -- You received this message because you are subscribed to the Google Groups "jackson-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to jackson-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-dev/522e3d6a-2811-42d3-94e7-2d1c5660ecffn%40googlegroups.com.
