CI/CD GitHub Actions setup-java switch to Azul Zulu builds of the OpenJDK

[Carl Dea]

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 

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  

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

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

[Tatu Saloranta]

Opinions, anyone? This sounds reasonable, in general, but I really haven't had time to investigate this any further.

So I would appreciate community members help here.

-+ Tatu +-

 

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...@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.