Require projects specify Java version in .tool-versions
so we build with that version, use Java 21 LTS elsewhere
#31
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-java
support for.tool-versions
is somewhat broken:java-version-file
withasdf
's.tool-versions
fails for Corretto, also non-strict semver versions聽actions/setup-java#615Using our own parsing of the
.tool-versions
file 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-java
to read it from our asdf.tool-versions
file 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-workflow
where 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-versions
file - this means we're now actually requiring them to have a.tool-versions
file, 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 Stream
chat 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-workflow
uses 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:X
in sbtscalacOptions
We do recommend that repos specify the
-release
flag in theirbuild.sbt
scalacOptions
, 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.