-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add JDK 21 to build matrix #1666
Comments
https://github.com/adoptium/temurin21-binaries/ doesn't have any binaries yet, but it should be fine to use the ones at https://jdk.java.net/21/ |
steps
|
I triggered test runs, but they're (as expected) failing because sbt is using Scala 2.12.17 which doesn't work on JDK 21. Can I find a way to have dbuild start sbt with If not, we'll have to:
|
looks like this will work: community.conf
- sbt-java-options: ["-Xms1536m", "-Xmx1536m", "-Xss2m"]
+ sbt-java-options: ["-Xms1536m", "-Xmx1536m", "-Xss2m", "-Dsbt.scala.version=2.12.18-M2"] |
some repos (e.g. specs2) will hit this: probably enough repos will avoid this that we'll get some reasonably satisfactory level of testing now? with more to come later once we're off 2.12.8-M2 and onto 2.12.18. it's fine, 21 is still early-access |
and that means we can't use |
and the scalac-scoverage-plugin problem prevents projects from even extracting :-( so this isn't actually going to be mergeable until after 2.12.18 is out. however, I could still do some runs on branches, using a restricted set of projects |
gah. this is too much hassle. let's take this up after 2.12.18 is out and we have an sbt release that uses it. JDK 21 is still EA, there's still plenty of time to fix any further issues, if any crop up. |
2.12.18 and sbt 1.9.0 are out on 2.13.x, it looks like we only need a few small changes: #1671 2.12.x will be harder (too hard, perhaps) since there are still sbt 0.13.x projects involved |
2.13.x is green after one more change (63a883b) — same projects fail as on JDK 20 for 2.12.x, I guess I'll make a branch with a subset |
that subset could end up being quite small, since the list of sbt 0.13 based projects:
includes projects such as scalatest (158 downstream projects) and macro-compat (61 downstream projects) some possible ways forward:
probably using binary dependencies as needed makes the most sense? |
I don't think it will be possible for me to tackle this until August |
Since we have the 2.13.12 release coming up, today I upgraded all 3 behemoths to JDK 21 EA build 35 (dated August 11, from https://jdk.java.net/21/):
steps
|
I'd like to get back on all-Temurin, just for consistency's sake, so I'll upgrade the behemoths once 21 appears at https://adoptium.net/temurin/releases/ |
this seems like confirmation that waiting for official Temurin is okay (and won't take too long): https://fosstodon.org/@sxa/111098188725062282 |
21 is here! https://adoptium.net/temurin/releases/ |
behemoths
steps
result
trigger builds
the console log should show the new version near the top delete old JDK 20 jobs
update wikihttps://github.com/scala/community-build/wiki#what-variations-of-the-build-exist |
upgrade to Temurin 21 final is complete leaving this open since I still need to figure out what to do, if anything, about the 2.12.x build |
Since I've been working on this at widely spaced intervals, I'd forgotten what the current set of blockers might be. Some of the above remarks were made before 2.12.18 was out. But it is out now, and scalac-scoverage-plugin is available for it. So perhaps it's possible to at least make everything extract if we
so the sbt 0.13 based projects are extracting; the ones that fail to extract are the ones stuck on sbt 1.3, 1.4, or 1.5. Hmm, but the only versions of scalac-scoverage-plugin published for 2.12.18 are 2.0.10 and 2.0.11, which are quite now, so of course these older projects aren't using that new of a version number. So I'd have to fork each project and either upgrade or remove scoverage. (And I wonder if upgrading would even work? Perhaps the latest scalac-scoverage-plugin uses sbt APIs that are too new? Maybe it doesn't matter, since it's simplest to just remove the plugin.) As a test, let me see if I can get specs2 extracting by removing scoverage from our fork (many of these projects are probably already forked) without breaking it on earlier JDKs. Yay, that worked. Next: add |
Hmm, that prevents some projects from extracting even on lower JDKs: coursier needed a macro paradise version bump (but that alone wasn't enough) curryhoward needed scoverage removed that leaves the following projects with a weird enumeratum and coursier I was able to get onto sbt 1.9.7 in forks sbt-util and sbt, I'll try the same Yay, everything extracts now (on 21, and on <21)! We'll see if there are any build failures. |
Closing as complete, since I can deal with any remaining build failures individually (by fixing them, or by marking them as expected-to-fail) — it's known that the fundamental issues are solved. |
We've already discovered and fixed an incompatibility on JDK 21 (scala/bug#12783) for 2.12.18 + 2.13.11. For additional validation of the fix, and to catch any other such problems going forward, I think it would be wise to get out ahead of this and add JDK 21 to the matrix while it's still in early-access.
I hypothesize that we have enough disk space. If it turns out to be too much pressure on that, lowering the frequency of the runs might help.
previous JDK 20 PR, to raid for details: #1581
The text was updated successfully, but these errors were encountered: