Run the build on JDK 18 and/or 19?

[SethTisue]

One reason I haven't done this yet is that three JDK versions is about all we have room for on our Jenkins config. We can't drop 8, and it isn't clear to me that dropping 11 or 17 in favor of 18 or 19 is a good trade.

On the other hand, JDK 18 has been out since March. (At present JDK 19 is still early-access.)

Perhaps we should try dropping 17 for 18 and see how many projects break. If almost nothing breaks, then I guess we might as well upgrade. But if there is substantial breakage, then maybe upgrading isn't such a good idea.

[He-Pin]

JDK 19 will be released on 9.20

[SethTisue]

JDK 19 is out. Early access builds of JDK 20 are available

[SethTisue]

I think a reasonable timetable is: wait for JDK 20 to come out, in March 2023, then try dropping 17 for 20. That'll give us time to straighten out issues, if any, in advance of JDK 21 which is the next LTS.

[SethTisue]

since we'll be building 2.12.18 and 2.13.11 in the coming weeks, I'd like to tackle this now — it would be awkward if some problem turned up shortly after we'd just released

[SethTisue]

• [x] behemoth 1

• [x] behemoth 2

• [x] behemoth 3

  • cd /usr/lib/jvm
  • sudo rm java-20-openjdk-x64
  • sudo curl -O -L 'https://github.com/adoptium/temurin20-binaries/releases/download/jdk20-2023-03-03-19-46-beta/OpenJDK20U-jdk_x64_linux_hotspot_2023-03-03-19-46.tar.gz'
  • sudo dtrx -n OpenJDK20U-jdk_x64_linux_hotspot_2023-03-03-19-46.tar.gz
  • sudo rm OpenJDK20U-jdk_x64_linux_hotspot_2023-03-03-19-46.tar.gz
  • sudo chmod -R go+rX OpenJDK20U-jdk_x64_linux_hotspot_2023-03-03-19-46
  • sudo ln -s OpenJDK20U-jdk_x64_linux_hotspot_2023-03-03-19-46/jdk-20+36 java-20-openjdk-x64
  • ./java-20-openjdk-x64/bin/java -version

openjdk version "20-beta" 2023-03-21
OpenJDK Runtime Environment Temurin-20+36-202303030331 (build 20-beta+36-202303030331)
OpenJDK 64-Bit Server VM Temurin-20+36-202303030331 (build 20-beta+36-202303030331, mixed mode, sharing)

[SethTisue]

made configs:

• https://scala-ci.typesafe.com/job/scala-2.12.x-jdk20-integrate-community-build/
• https://scala-ci.typesafe.com/job/scala-2.13.x-jdk20-integrate-community-build/

[SethTisue]

👀

• https://scala-ci.typesafe.com/view/scala-2.12.x/job/scala-2.12.x-jdk20-integrate-community-build/9/
• ~https://scala-ci.typesafe.com/view/scala-2.13.x/job/scala-2.13.x-jdk20-integrate-community-build/3/~
• https://scala-ci.typesafe.com/job/scala-2.13.x-jdk20-integrate-community-build/5

[SethTisue]

2.12

all the sbt 0.13 projects in the 2.12 build fail to extract, as per https://github.com/sbt/sbt/issues/6558, with [scala-collection-laws:error] java.lang.UnsupportedOperationException: The Security Manager is deprecated and will be removed in a future release

I'm also seeing e.g.

[specs2:error] java.lang.ClassCastException: class java.lang.UnsupportedOperationException cannot be cast to class xsbti.FullReload because specs2 is on sbt 1.5

I didn't look at every extraction error one by one — the sbt 0.13 thing will need to be dealt with first

[SethTisue]

2.12

looks like I can work around the Security Manager thing with extra.options: ["-Djava.security.manager=allow"]

[SethTisue]

Both builds now extract and have been humming along for a few hours. Stay tuned

[SethTisue]

looks like I can work around the Security Manager thing with extra.options: ["-Djava.security.manager=allow"]

arrghhhh... JDK 8 and JDK 11 do not accept this

not sure what to do here — maybe patch dbuild to do the right thing depending on JDK version? sigh

[SethTisue]

oh, I think I can bust out my HOCON fu and put ${?OLD_SBT_COMPAT} in extra.options, then alter the run script to leave that environment variable unset on JDK 8 and 11, but set it on JDK 17+ 🧠

[SethTisue]

2.13

• zinc: "java.lang.IllegalArgumentException: Unsupported class file major version 64" during shading
• ssl-config: "value set is not a member of sun.security.x509.X509CertInfo"
• specs2: org.specs2.execute.EventuallyResultsSpec fails
• slick: slick.test.jdbc.MBeansTest fails
• scallop: calls java.lang.System.setSecurityManager
• kafka: cannot override final member threadId
• better-files: better.files.FileSpec fails

[SethTisue]

2.12

• scalaj-http: "Source option 7 is no longer supported. Use 8 or later"
• parboiled: "Source option 7 is no longer supported. Use 8 or later"
• breeze: "Source option 7 is no longer supported. Use 8 or later"
• ssl-config: same as 2.13
• slick: same as 2.13
• scallop: same as 2.13

[SethTisue]

I've investigated the failures sufficiently to be reasonably confident that there aren't Scala regressions here.

Closing since that's the primary goal, but I'll continue to pursue getting the jobs green, either with fixes/workarounds, or by marking them as expected-to-fail.