Check ct.sym first before falling back to jrt

[srdo-humio]

Since Turbine is used via a GraalVM native image in Bazel, jrt is not enabled, so looking up the bootclasspath that way doesn't work.

As of Java 22, ct.sym contains signatures for all supported JDKs, so there is no need to look in jrt.

Partial fix for bazelbuild/bazel#21895

[srdo-humio]

@cushon I think this should fix the issue when using a ct.sym from Java 22+. For older JDKs, this shouldn't change behavior much, we should look in ct.sym and not find a match, and then try jrt after that.

Do you know if it's written down somewhere how I would go about testing this? I assume I'd need to get java_tools to point to a locally-built turbine jar, and then do https://github.com/bazelbuild/java_tools/blob/master/docs/behind-the-release.md#manually-trying-out-java_tools-before-the-release-process?

[cushon]

Thanks for this!

Do you know if it's written down somewhere how I would go about testing this?

I think those docs are out of date, the approach I've used is: bazelbuild/java_tools#43 (comment)

[srdo-humio]

@cushon Thanks, your linked guide worked for testing this, though I had some difficulty with bazelbuild/bazel#21935.

Using this patch, I can build code with --release 21 using a toolchain that gets ct.sym from a Java 22 install. So I think this works as it should now.

I think the test failure might be unrelated, mvn test passes for me locally. I've rebased on top of the latest commit to see if that fixes the test on CI.

[cushon]

Thanks, I had started the process to import this and it got stuck, I think I have unstuck it now.

The test failure I saw was unrelated and only on JDK EA versions, and should have been resolved by 74c2c36.