Turbine: error: missing required annotation argument: <clinit>

[mskonovalov]

Description of the problem / feature request:

Have a java + spring target that builds successfully but fails during Intellij sync.

Server.java:56: error: missing required annotation argument: <clinit>
@CrossOrigin(
^

I was able to checkout turbine and reproduce the bahavior - it works on latest master of turbine.
It seems this has been fixed in turbine 5 month ago google/turbine@617a8f6 but bazel still has the old version of turbine.

What operating system are you running Bazel on?

MacOs, Linux

What's the output of bazel info release?

release 4.1.0- (@non-git)

If bazel info release returns "development version" or "(@Non-Git)", tell us how you built Bazel.

from nix

Have you found anything relevant by searching the web?

https://stackoverflow.com/questions/45656877/crossorigin-annotation-doesnt-compile
google/turbine@617a8f6

[aiuto]

This seems like just updating the third_party dependency will fix it.

[mskonovalov]

I hope it should. What is the process around this?

[aiuto]

Someone on the bazel team has to update things in //third_party.
It has the appropriate label, so the right people should pick it up in their triage.

[cushon]

cc @comius

The turbine fix made it into java_tools v11.2 per #13144 (comment), this will be fixed in Bazel 4.2

[twheys]

I was running into this issue on Bazel 4.1.0. Just tried upgrading to Bazel 4.2.0 and I still have the issue. Was this maybe missed? Does anyone know if there's a work-around for the time being?

[cushon]

@comius did the java_tools update not make it into 4.2.0?

@twheys does adding this to your WORKSPACE to update to the latest java_tools version make a difference? https://github.com/bazelbuild/java_tools/releases/tag/java_v11.3

[twheys]

Hi @cushon - I tried adding the java_tools 11.3 rules to my WORKSPACE file and that results in some errors about missing targets. I tried running bazel clean --expunge to no avail. I am on Bazel 4.2.0

ERROR: /private/var/tmp/_bazel_theys/c47bd7bac752f67cacbe3862d74d80c0/external/bazel_tools/tools/jdk/BUILD:279:28: no such target '@remote_java_tools_darwin//:java_tools/JacocoCoverage_jarjar_deploy.jar': target 'java_tools/JacocoCoverage_jarjar_deploy.jar' not declared in package '' defined by /private/var/tmp/_bazel_theys/c47bd7bac752f67cacbe3862d74d80c0/external/remote_java_tools_darwin/BUILD and referenced by '@bazel_tools//tools/jdk:JacocoCoverageFilegroup'

[philwo]

FYI @comius

[comius]

Bazel 4.2.x is using the old Java resolution mechanism, so it has java_tools 10.6. (java_tools 11.x don't work with it).

Since it's a LTS, we should update old java_tools. It requires hand crafting a back-patch.

[oliviernotteghem]

4.2.0 lists turbine fix as cherry picked. However, I think it was missed, as the version on 4.2.0 is not right (see below). This probably why folks are still seeing issue on 4.2.x ? cc @comius

EDIT : the JAR checked in are actually not used by bazel binaries. Turbine is pulled instead from java_tools, which are still on 10.6 for bazel 4.2.0, hence don't contain the fix.

Here is the workaround :

1. Import in your WORKSPACE v11.2 of the java tools (which contains the fix to Turbine)

# Import java tools rules, as it is used by our own java toolchain (to use a patched version of Turbine).
http_archive(
    name = "remote_java_tools",
    sha256 = "b6c468410a371728fe703ef7a6e386bb7f69bb46b900fed0460eb68c54f99895",
    urls = [
            "https://mirror.bazel.build/bazel_java_tools/releases/java/v11.2/java_tools-v11.2.zip",
            "https://github.com/bazelbuild/java_tools/releases/download/java_v11.2/java_tools-v11.2.zip",
    ],
)

2. Override the version of Turbine used in your toolchain with that version :

java_toolchain(
  .....
  header_compiler = ["@remote_java_tools//:TurbineDirect"],
  header_compiler_direct = ["@remote_java_tools//:TurbineDirect"],
  ....
)

[comius]

I made a new release of java_tools v10.7, https://github.com/bazelbuild/java_tools/releases/tag/javac11_v10.7.

This issue should be fixed by including http_archives mentioned in the release notes into the WORKSPACE files (without any need to do custom toolchains). That is if you're on Bazel 4.x.x.

Bazel 5.0.0 should have no such issues.