ci: build by java high version and test by multi java versions(WIP)

[oldratlee]

Still WIP... 🚧 the implemetation codes need be simplified and polished.

The reasons to create the WIP PR:

• show the working progress
• ask questions
• get feedback early

Work items and their progress

• [x] update GitHub Actions config(.github/workflows/maven.yml) and add running script(scripts/integration-test.sh)
  • build/compile/test with java 21 by mvn package
  • test with multiply java versions(e.g. 8/11.0.3/11/17) by mvn surefire:test
• [ ] fix test cases failure with java 8
• ...

Related infos

• the related PR:
  • https://github.com/jboss-javassist/javassist/pull/477#discussion_r1438758200
• more WIP commits at tempory repo expt-javassist-ci
  • use the tempory repo to experiment and tigger the CI actions for every commits
  • more WIP commits: https://github.com/quickhack/expt-javassist-ci/commits/master/

[oldratlee]

Is the specified old java version 11.0.3 in CI significant?

https://github.com/jboss-javassist/javassist/blob/7302b8b0a09f04d344a26ebe57f29f3db43f2a3e/.github/workflows/maven.yml#L18-L20

If the newest Java 11 version is enough and remove 11.0.3 in CI, the CI script(scripts/integration-test.sh) could be simplified a lot.

---

Found the info about adding the specified java version 11.0.3 in commit b7838d44abe1c3a3fd762061ac8c16fea4d509f3 by @carldea:

Using TCK Tested JDK builds of OpenJDK

The AdoptOpenJDK has been discontinued since July 2021. When using Zulu you get all the latest updated (TCK Tested) builds for all versions of OpenJDK.

Also added are fixed (major) release version(s) such as 11.0.3.

This is often a good practice whenever a build/test triggers (push/pull events) this can determine if the latest JDK (11) had failed the build vs something in your code that caused it.

For example, when building with JDK 11.0.3 (fixed version) the build passes (green) and JDK 11 fails (red) will mean that the latest JDK (11) was the cause and not your code.

@carldea

I agree that "adding an old fixed (major) release version(s)" is often a good practice.

Because

• after introducing "build by java high version and test by multi java versions (LTS 8/11/17/21)", "adding an old fixed (major) release version(s)" practice adding many old versions into a workflow
• if the CI run continuously, it's possible to "determine if the latest JDK (11) had failed"
• if "the latest JDK (11) had failed" happened(low probability case & can not be ignored), can add a new workflow to reproduce the case

, how about removing the specified old java version 11.0.3 in CI?