chore(deps): Update Scala, sbt and JDK

[reneleonhardt]

Updates:

• Build with sbt 1.9.9 and scala 2.12.19, 2.13.14 and 3.3.3
• JDK 21.0.1 to 21.0.3
• Most dependencies

Improvements:

• Download official https://wiki.openjdk.org/display/JDKUpdates/JDK+21u#JDK21u-LatestRelease binaries including checksum
• Streamline adopt to temurin in GitHub Action

I could build with JDK 21, can you double-check?
https://docs.scala-lang.org/overviews/jdk-compatibility/overview.html#scala-compatibility-table
Then you could add 21 to the matrix 😅

[lbulej]

Thanks for the PR, I'm just afraid it can't go as is, because you are changing too many different things (CI, SBT, benchmarks, platform versions) and suites like this are rather sensitive when it comes to version numbers.

• With Scala 3, the plan is to stay on the LTS branch (3.3), especially if moving to 3.4 breaks a benchmark.
• With SBT, I would tend to delay 1.10 and move to 1.9.9 instead (note that we include the binaries in the repository for convenience, so they need to be updated as well and 1.10 will be changing rather frequently now).
• Changes in benchmarks/scala-stm/scala-stm-library/dep_tests/sbt/build.sbt should not be necessary, because they are not used.
• The runtimeInfo() method in benchmarks/actors-akka/src/main/java/edu/rice/habanero/benchmarks/Benchmark.java is also not used anywhere (the code is there just because the original idea was to import the benchmark without much changes).
• We did not find a need for semantic/conventional commits (yet), for example because what may seems as chore (dependency update such as changing Scala version) may actually change workloads or break benchmarks and needs to pass through CI

[reneleonhardt]

Thanks for the infos, did I catch/revert everything?
I extracted https://github.com/sbt/sbt/releases/download/v1.9.9/sbt-1.9.9.tgz but now the diff is showing the executable bit 100644 → 100755, is that as intended or should I --chmod=-x those files? 😅

[reneleonhardt]

I updated all dependencies, the only one changing the Java version was ASM 9.7 (8 to 11).

[lbulej]

Doesn't chronicle-map pickup the affinity dependency automatically?

[reneleonhardt]

For me it didn't build anymore, they have a strange dependency management... ymmv, just remove this line and try yourself 😅

[lbulej]

Various missing BOMs (or what not) was the reason I did not update to the latest versions previously (for release 0.15) and stuck to the versions SBT was able to build with.

[lbulej]

I don't understand the comment, perhaps you meant "the least version to support JDK21"?

[reneleonhardt]

As far as I understood this mess, dotty 3.3.1 is the last version to support JDK 21, everything newer broke my builds.
But be my guest and try 3.3.2 or 3.3.3 yourself, maybe you have more luck 😅

[lbulej]

OK, what confused me was the reference to the JDK-8308050, which referenced #384 here a while ago, and which was resolved in #404 by using dotty 3.3.1 on Scala 3. I would not expect things to break in 3.3.2 again. Is the Scala 3 commit you reference the commit that broke things?

[lbulej]

Perhaps this could be replaced with scalaVersion3. I think the explicit version is a leftover from the time we used dotty3 with Scala 2.13.

[lbulej]

OK, with respect to the above, we may need to keep scala3-compiler_3 version separate from scalaVersion3. How odd.

[lbulej]

Thanks for the infos, did I catch/revert everything? I extracted https://github.com/sbt/sbt/releases/download/v1.9.9/sbt-1.9.9.tgz but now the diff is showing the executable bit 100644 → 100755, is that as intended or should I --chmod=-x those files? 😅

Yes please, strip the executable bit from the .bat, .jar, and .exe files.

[lbulej]

In general, this is going in the right direction, thank you!

I would appreciate if you could split off the (SBT + CI) update and the benchmark dependency updates into two separate PRs.

Also, in the PR with benchmark platform/dependency updates, could you please list the platform (i.e. Scala) and the primary dependency updates per benchmark in the PR message?

This is to make version changes easier to see, because they are not just a chore. I often end up with separate commits for primary dependency updates to individual benchmarks and prior to release I try to unify the versions of common (second-level) dependencies. But given that the CI is not complaining now, I'm fine with the bundle :-)