--experimental_check_desugar_deps (on by default) breaks Android builds with remote execution

[akirchhoff-modular]

Description of the problem / feature request:

When building an android_binary using remote execution and without explicitly passing --noexperimental_check_desugar_deps, the build will fail with this error:

singlejar_cc_bin: external/remote_java_tools_linux/java_tools/src/tools/singlejar/singlejar_main.cc:27: Desugar checking not currently supported in Bazel.

Feature requests: what underlying problem are you trying to solve with this feature?

N/A

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Download and extract repro.zip. Run

bazel build //subject:app

Observe that the application builds correctly. Then try building it remotely:

bazel build --config=remote --remote_instance_name=projects/<project ID>/instances/default_instance //subject:app

(Replacing <project ID> with a Google Cloud project ID that has Remote Build Execution set up. This can also be reproduced without RBE by using a local @io_bazel//src/tools/remote:worker by passing the appropriate flags.) Observe the following failure:

ERROR: <...>/repro/subject/BUILD:1:1: Building deploy jar subject/app_deploy.jar failed (Exit 1)
singlejar_cc_bin: external/remote_java_tools_linux/java_tools/src/tools/singlejar/singlejar_main.cc:27: Desugar checking not currently supported in Bazel.
Target //subject:app failed to build

Now try adding --noexperimental_check_desugar_deps to the command line. Observe that it succeeds.

What operating system are you running Bazel on?

Ubuntu 16.04.6 LTS

What's the output of bazel info release?

release 0.29.0

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

N/A

What's the output of git remote get-url origin ; git rev-parse master ; git rev-parse HEAD ?

N/A (Bazel binary from GitHub releases; repro repository provided as ZIP above)

Have you found anything relevant by searching the web?

Yes. This flag was flipped in Bazel 0.21 and was mentioned in the release notes:

Android

• --experimental_check_desugar_deps is enabled by default. This flag rules out several types of invalid Android builds at compile-time. Note that this is incompatible with remote Android builds, so you can disable it with --noexperimental_check_desugar_deps.

There is also a comment in the code that references what I assume to be a Google-internal issue, b/67733424, which I'm guessing has about the same information as in this issue, but I can't see it because I'm not a Googler and no public bugs were ever filed on this issue as far as I can tell.

Any other information, logs, or outputs that you want to share?

It was unclear to me why singlejar_main.cc and singlejar_local_main.cc both existed and why the remote one doesn't support desugar checking -- naïvely it seems like it would be sufficient to have only one, and have it be used both locally and remotely. After some investigation, I think I've figured out why it is the way it is. Local builds can use a pre-built singlejar, which can incur whatever dependencies it wants, as it's built at the time Bazel is built. Remote builds don't actually use a singlejar included with Bazel at all -- they use a remote repository from src/main/java/com/google/devtools/build/lib/bazel/rules/java/jdk.WORKSPACE (which don't automatically reflect the version of singlejar Bazel was built with -- it requires snapshots to be taken and uploaded somewhere, then the URLs and hashes updated in that file) that fetches singlejar's source code, and the singlejar used for remote builds is then built on-the-fly. Desugar checking relies on a Protobuf, which is easy to include for the prebuilt version, but Protobuf is not necessarily available when built as a repository somewhere within someone else's build.

So far as I can tell, that's the only issue -- I tried hacking up the BUILD files such that the prebuilt version is always used, and it works just fine (when both the client Bazel and the remote execution backend are both running Linux on the same architecture, at least -- I'm not suggesting this as an actual solution, and more to demonstrate that I think the reason this was done was solely because of the Protobuf dependency, not anything more intricate). I'm also guessing the reason it says "in Bazel" in the error message is that this works fine in Blaze, because Blaze always (?) runs inside of google3, and in google3 it is safe to assume you will always have Protobuf available.

[jin]

Yes, this is a known issue with anything that uses singlejar with RBE.

Also, see https://github.com/jin/android-testing/blob/rbe/.bazelrc for a bazelrc that works for Android projects building on RBE.

[github-actions[bot]]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 2+ years. It will be closed in the next 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

[akirchhoff-modular]

I no longer have access to an RBE environment, so this is not easy for me to test. But I expect the repro attached in the issue would be able to be easy to run to see if there is still an issue or not, for someone who does have access to an RBE environment.

[seabass-labrax]

This issue also applies when building locally on my system. Adding --noexperimental_check_desugar_deps is a working solution here as well.

Tested on an verbatim version of the Bazel Android tutorial with Bazel release 6.0.0 installed via Nix, Android SDK and associated tools installed via sdkmanager, Debian 11 (Bullseye) on Linux AMD64.

[seabass-labrax]

I can also reproduce the issue with Bazel 6.4.0 installed via Nix (in all other respects the same configuration as last time).