Require projects specify Java version in .tool-versions so we build with that version, use Java 21 LTS elsewhere
#31
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rtyley
changed the title
rtyley
changed the title
John Duffell has reported improved speed from Java 21 LTS: https://chat.google.com/room/AAAAag0I08g/Nvinl3aN_cU/ ...and Mariot has confirmed that we should be encouraging people to move to Java 21. In `gha-scala-library-release-workflow` we always use the same version of Java to _compile_ the project, regardless of the repo, because we've not yet encountered a need to configure the Java on a pre-repo basis. However, we do recommend that repos specify the `-release` flag in their `build.sbt` `scalacOptions`, which specifies the minimum release of Java that should be supported in the resulting artifacts - we still have some systems runinng on Java 8, so unfortunately they need `-release:8` https://docs.scala-lang.org/overviews/jdk-compatibility/overview.html#jdk-21-compatibility-notes
rtyley
added a commit
to guardian/etag-caching
that referenced
this pull request
Mar 14, 2024
This is motivated by guardian/gha-scala-library-release-workflow#31 - initially I was just thinking about updating to Java 21, but now I think that making projects declare which Java version they use to build is probably a good thing! Note that we're using asdf's .tool-versions file here, which has recently gained support in actions/setup-java#606 - this means that we can also get _all_ our GitHub Actions files to respect the Java version definied in that file - eg, we can reference it in ci.yml, and we don't need to update Java version in there anymore.
rtyley
commented
Mar 14, 2024
| @@ -115,7 +121,7 @@ jobs: | |||
| - uses: actions/setup-java@v4 # don't 'cache: sbt', at least until https://github.com/actions/setup-java/pull/564 is merged | |||
| with: | |||
| distribution: corretto | |||
| java-version: 17 | |||
| java-version-file: ${{ inputs.LIBRARY_BUILD_JAVA_VERSION_FILE }} | |||
There was a problem hiding this comment.
When we run the library's build process, let's respect the .tools-version that they supply - see actions/setup-java#606
rtyley
changed the title
.tool-versions so that we can build with that version, use Java 21 LTS elsewhere
rtyley
changed the title
.tool-versions so that we can build with that version, use Java 21 LTS elsewhere.tool-versions so we build with that version, use Java 21 LTS elsewhere
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Unfortunately this PR is is somewhat blocked, as
actions/setup-javasupport for.tool-versionsis somewhat broken:java-version-filewithasdf's.tool-versionsfails for Corretto, also non-strict semver versions聽actions/setup-java#615Using our own parsing of the
.tool-versionsfile may be a way around this, eg:Respect
.tool-versions!Thanks to these PRs in the GitHub Action
actions/setup-java:...we no longer need to additionally specify a Java version number in GitHub Workflow YAML (eg in ci.yml - instead, we can just tell
actions/setup-javato read it from our asdf.tool-versionsfile as a source of truth - one less place to update when we upgrade Java, and better documentation and UX for developers!For the 2 places in our
gha-scala-library-release-workflowwhere we run the library repo's build process (ie馃帄 Test & Version&馃帄 Create artifacts), its best that we use whatever version of Java they specify in their.tool-versionsfile - this means we're now actually requiring them to have a.tool-versionsfile, which is not really a big imposition - better standardisation.Note problems encountered in https://github.com/actions/setup-java/pull/606/files#r1524819663
Java 21 LTS
John Duffell reports in
P&E/DevX Streamchat and guardian/support-frontend#5792 that Java 21 LTS delivers improved lambda-startup time over Java 11 (the performance improvements may have occurred in versions of Java between 11 and 21, not sure, but definitely seen in Java 21), and Mariot has confirmed that we should be encouraging people to move to Java 21.gha-scala-library-release-workflowuses Java for several of its stages, and only 2 of those stages need to use the version of Java required by the library project, so for the others, we just use the latest LTS version of Java - Java 21 LTS.-release:Xin sbtscalacOptionsWe do recommend that repos specify the
-releaseflag in theirbuild.sbtscalacOptions, which specifies the minimum release of Java that should be supported in the resulting artifacts - without this flag, the built artifacts will only support the version of Java they were compiled with, or above - and we may well want to take advantage of compiling with a newer version of Java, even if we have to release artifacts compatible with older versions of Java for services that have not updated yet.