ArrayIndexOutOfBoundsException in turbine with JDK 21 class files

[cushon]

Building with class files emitted by the JDK 21 javac will result in crashes like the following:

java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 207
        at com.google.turbine.bytecode.ConstantPoolReader.utf8(ConstantPoolReader.java:120)
        at com.google.turbine.bytecode.ClassReader.readMethodParameters(ClassReader.java:229)
        at com.google.turbine.bytecode.ClassReader.readMethods(ClassReader.java:438)
        at com.google.turbine.bytecode.ClassReader.read(ClassReader.java:105)
        at com.google.turbine.bytecode.ClassReader.read(ClassReader.java:55)
        at com.google.turbine.binder.bytecode.BytecodeBoundClass$1.get(BytecodeBoundClass.java:91)
        at com.google.turbine.binder.bytecode.BytecodeBoundClass$1.get(BytecodeBoundClass.java:88)
        at com.google.common.base.Suppliers$NonSerializableMemoizingSupplier.get(Suppliers.java:183)
        at com.google.turbine.binder.bytecode.BytecodeBoundClass$6.get(BytecodeBoundClass.java:194)
        at com.google.turbine.binder.bytecode.BytecodeBoundClass$6.get(BytecodeBoundClass.java:191)
        at com.google.common.base.Suppliers$NonSerializableMemoizingSupplier.get(Suppliers.java:183)
        at com.google.turbine.binder.bytecode.BytecodeBoundClass$7.get(BytecodeBoundClass.java:207)
        at com.google.turbine.binder.bytecode.BytecodeBoundClass$7.get(BytecodeBoundClass.java:204)
        at com.google.common.base.Suppliers$NonSerializableMemoizingSupplier.get(Suppliers.java:183)
        at com.google.turbine.binder.bytecode.BytecodeBoundClass.typeParameters(BytecodeBoundClass.java:221)
        at com.google.turbine.types.Canonicalize.isRaw(Canonicalize.java:152)
        at com.google.turbine.types.Canonicalize.canon(Canonicalize.java:127)
        at com.google.turbine.types.Canonicalize.canonicalizeClassTy(Canonicalize.java:360)
        at com.google.turbine.types.Canonicalize.canonicalize(Canonicalize.java:115)
        at com.google.turbine.types.Canonicalize.canonicalize(Canonicalize.java:366)
        at com.google.turbine.types.Canonicalize.canonicalizeClassTy(Canonicalize.java:357)
        at com.google.turbine.types.Canonicalize.canonicalizeClassTy(Canonicalize.java:87)
        at com.google.turbine.binder.CanonicalTypeBinder.bind(CanonicalTypeBinder.java:52)
        at com.google.turbine.binder.Binder.canonicalizeTypes(Binder.java:319)
        at com.google.turbine.binder.Binder.bind(Binder.java:172)
        at com.google.turbine.binder.Binder.bind(Binder.java:97)
        at com.google.turbine.main.Main.bind(Main.java:259)
        at com.google.turbine.main.Main.compile(Main.java:157)
        at com.google.turbine.main.Main.compile(Main.java:132)
        at com.google.turbine.main.Main.main(Main.java:88)

The latest JDK 21 builds contain some system classes with MethodParameters attributes that contain empty names. This change was caused by the fix for JDK-8292275: javac does not emit SYNTHETIC and MANDATED flags for parameters by default.

Turbine was fixed to correctly handle these class files in google/turbine@0f20345, but that change isn't available in Bazel yet.

I opened https://github.com/bazelbuild/bazel/pulls to update turbine. We should merge that fix and cut a java_rules release that includes the change before JDK 21 is released in September.

[cushon]

@bazel-io flag

[iancha1992]

@bazel-io fork 6.3.0

[iancha1992]

@cushon Was this pushed? If yes, then can you please direct me to the PR or commit ID so we can cherry-pick to 6.3.0?

[cushon]

@iancha1992 It was merged as aff3361

[iancha1992]

@cushon Looks like this is a jar file change. I'm trying to cherrypick this commit, but can't due to conflicts. Any advice?

[cushon]

Is the baseline for 6.3.0 from around October 2022? I didn't realize it was that old.

There have been a few updates of turbine since then, and the version in 6.3.0 hasn't got the last few updates:

• https://github.com/bazelbuild/bazel/commits/release-6.3.0/third_party/turbine
• https://github.com/bazelbuild/bazel/commits/master/third_party/turbine

We just want the latest version of third_party/turbine/turbine_direct.jar, it would be safe to resolve the merge conflict by taking the latest version of the .jar. Instead of cherry-picking it might be easier to create a PR against 6.3.0 that just copies over the latest version.

[Wyverald]

The merge base with master for all 6.x is 6.0 (so indeed Oct 2022). 6.3.0 is based on 6.2.X, which is based on 6.1.X, etc.

Liam, if you could prepare the PR against 6.3.0, that would be great. It should be as simple as checking out the release-6.3.0 branch, making the changes you want, and opening a PR.

[cushon]

Done: #18803

[hvadehra]

@cushon Can we close this as resolved?

[shahms]

Maybe I'm holding it wrong, but I'm still seeing this exception with JDK21 and Bazel 6.3.0 and 6.3.2:

$ bazel test --verbose_failures --config=remote  --config=java21 //kythe/java{,tests}/...
...
    PATH=/bin:/usr/bin:/usr/local/bin \
  external/remotejdk21_linux/bin/java '--add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED' '--add-exports=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED' '--add-exports=jdk.compiler/com.sun.tools.javac.model=ALL-UNNAMED' '--add-exports=jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED' '--add-exports=jdk.compiler/com.sun.tools.javac.resources=ALL-UNNAMED' '--add-exports=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED' '--add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED' '--add-opens=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED' '--add-opens=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED' '--add-opens=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED' '--add-opens=jdk.compiler/com.sun.tools.javac.parser=ALL-UNNAMED' '--add-opens=java.base/java.nio=ALL-UNNAMED' '--add-opens=java.base/java.lang=ALL-UNNAMED' '-Dsun.io.useCanonCaches=false' -XX:-CompactStrings -jar external/remote_java_tools/java_tools/turbine_direct_binary_deploy.jar --output bazel-out/k8-opt-exec-5CCBED07/bin/external/rules_jvm_external/private/tools/java/com/github/bazelbuild/rules_jvm_external/zip/libzip-hjar.jar --output_deps bazel-out/k8-opt-exec-5CCBED07/bin/external/rules_jvm_external/private/tools/java/com/github/bazelbuild/rules_jvm_external/zip/libzip-hjar.jdeps --bootclasspath bazel-out/k8-opt-exec-5CCBED07/bin/external/rules_java/toolchains/platformclasspath.jar --sources external/rules_jvm_external/private/tools/java/com/github/bazelbuild/rules_jvm_external/zip/StableZipEntry.java --javacopts -source 21 -target 21 '-XDskipDuplicateBridges=true' '-XDcompilePolicy=simple' -g -parameters -Xep:ReturnValueIgnored:OFF -Xep:IgnoredPureGetter:OFF -Xep:EmptyTopLevelDeclaration:OFF -Xep:LenientFormatStringValidation:OFF -Xep:ReturnMissingNullable:OFF -- --target_label @@rules_jvm_external//private/tools/java/com/github/bazelbuild/rules_jvm_external/zip:zip --reduce_classpath_mode NONE)
# Configuration: 24d2a40b83cb11bc3d8e25258adeab78058cf68fb15c271dc7eb052605cc54ff
# Execution platform: //tools/platforms:rbe
java.lang.ArrayIndexOutOfBoundsException: Index -1 out of bounds for length 1442
        at com.google.turbine.bytecode.ConstantPoolReader.utf8(ConstantPoolReader.java:120)
        at com.google.turbine.bytecode.ClassReader.readMethodParameters(ClassReader.java:229)
        at com.google.turbine.bytecode.ClassReader.readMethods(ClassReader.java:438)
        at com.google.turbine.bytecode.ClassReader.read(ClassReader.java:105)
        at com.google.turbine.bytecode.ClassReader.read(ClassReader.java:55)
        at com.google.turbine.binder.bytecode.BytecodeBoundClass$1.get(BytecodeBoundClass.java:91)
        at com.google.turbine.binder.bytecode.BytecodeBoundClass$1.get(BytecodeBoundClass.java:88)
        at com.google.common.base.Suppliers$NonSerializableMemoizingSupplier.get(Suppliers.java:183)
        at com.google.turbine.binder.bytecode.BytecodeBoundClass$6.get(BytecodeBoundClass.java:194)
        at com.google.turbine.binder.bytecode.BytecodeBoundClass$6.get(BytecodeBoundClass.java:191)
        at com.google.common.base.Suppliers$NonSerializableMemoizingSupplier.get(Suppliers.java:183)
        at com.google.turbine.binder.bytecode.BytecodeBoundClass$7.get(BytecodeBoundClass.java:207)
        at com.google.turbine.binder.bytecode.BytecodeBoundClass$7.get(BytecodeBoundClass.java:204)
        at com.google.common.base.Suppliers$NonSerializableMemoizingSupplier.get(Suppliers.java:183)
        at com.google.turbine.binder.bytecode.BytecodeBoundClass.typeParameters(BytecodeBoundClass.java:221)
        at com.google.turbine.types.Canonicalize.isRaw(Canonicalize.java:152)
        at com.google.turbine.types.Canonicalize.canon(Canonicalize.java:127)
        at com.google.turbine.types.Canonicalize.canonicalizeClassTy(Canonicalize.java:360)
        at com.google.turbine.types.Canonicalize.canonicalize(Canonicalize.java:115)
        at com.google.turbine.types.Canonicalize.canonicalize(Canonicalize.java:77)
        at com.google.turbine.binder.CanonicalTypeBinder.param(CanonicalTypeBinder.java:166)
        at com.google.turbine.binder.CanonicalTypeBinder.parameters(CanonicalTypeBinder.java:153)
        at com.google.turbine.binder.CanonicalTypeBinder.methods(CanonicalTypeBinder.java:127)
        at com.google.turbine.binder.CanonicalTypeBinder.bind(CanonicalTypeBinder.java:66)
        at com.google.turbine.binder.Binder.canonicalizeTypes(Binder.java:319)
        at com.google.turbine.binder.Binder.bind(Binder.java:172)
        at com.google.turbine.binder.Binder.bind(Binder.java:97)
        at com.google.turbine.main.Main.bind(Main.java:259)
        at com.google.turbine.main.Main.compile(Main.java:157)
        at com.google.turbine.main.Main.compile(Main.java:132)
        at com.google.turbine.main.Main.main(Main.java:88)

$ bazel version
Bazelisk version: development
Build label: 6.3.2
Build target: bazel-out/k8-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Tue Aug 8 15:48:33 2023 (1691509713)
Build timestamp: 1691509713
Build timestamp as int: 1691509713

[cushon]

Maybe I'm holding it wrong, but I'm still seeing this exception with JDK21 and Bazel 6.3.0 and 6.3.2

@hvadehra any ideas?

I wonder if the fix needed a rules_java update as well for the fix to make it into the archive of Java tools, and that didn't happen for 6.3.0

[shahms]

Hm, it looks like updating to a newer version of rules_java toolchains fixes this. We run into google/error-prone#3976 but avoid this issue.

[cushon]

Hm, it looks like updating to a newer version of rules_java toolchains fixes this. We run into google/error-prone#3976 but avoid this issue.

Bazel at head is still on Error Prone 2.20.0, the version with the crash:

bazel/MODULE.bazel

Line 85 in b85f2d1

"com.google.errorprone:error_prone_core:2.20.0",

I'll update it, but it'll take some time to propagate to a rules_java release. For that crash a more expedient workaround is to just disable the check that's crashing with -Xep:MemberName:OFF

[shahms]

Thanks! That's the solution I've taken so far in my in-progress change. MemberName also catches a few other issues which we'll need to clean up, but am going to hold off until I can re-enable it.

[guw]

I am also seeing this exception with Bazel 6.4.0. It doesn't look like it's fixed. Did the rules_java update work for you @shahms?

[shahms]

It was a while ago, but ISTR that updating rules_java addressed this for us.

[vorburger]

@guw I've also hit this one on Bazel 6.4.0 while experimenting with switching to Java 21 in enola-dev/enola#426 for salesforce/bazel-vscode-java#85, and indeed updating rules_java with enola-dev/enola#427 makes this go away. (However I'm now hitting bazelbuild/rules_jvm_external#1013.)