Oppia Android: Bazel Build Fails On Mac Os Due To Missing Remote Java Tools Darwin

[Sandesh282]

Operating System

MacOS

Android Studio Version

Android Studio Giraffe | 2022.3.1 Patch 4

RAM size

8 GB

Free disk space

100 GB

Which step are you stuck on?

I am stuck at the local build step while following the official Oppia Android installation guide:

https://github.com/oppia/oppia-android/wiki/Installing-Oppia-Android

Specifically, the failure occurs at the step where the app is built or run using Bazel:

bazel build //:oppia_dev_binary

The error happens during Bazel analysis / toolchain resolution, before any project code is compiled.

Error Log

ERROR: external/rules_java/toolchains/BUILD:116:14:
no such package '@remote_java_tools_darwin//':
The repository '@remote_java_tools_darwin' could not be resolved
referenced by '@rules_java//toolchains:ijar_prebuilt_binary_darwin'

ERROR: Analysis of target '//:oppia_dev_binary' failed; build aborted

register_toolchains("@rules_java//toolchains:remote_toolchain")

ERROR: invalid registered toolchain '@rules_java//toolchains:remote_toolchain'

Approaches already used to resolve the issue

Approaches already used to resolve the issue

I tried the following troubleshooting steps:

Verified Bazel version matches .bazelversion (Bazel 6.5.0)

Confirmed Bazel is using remotejdk_11 via bazel info

Verified .bazelrc already enforces:

build --java_runtime_version=remotejdk_11
build --tool_java_runtime_version=remotejdk_11

Disabled bzlmod

Verified WORKSPACE includes:

rules_java_dependencies()
rules_java_toolchains()

Installed Xcode 15.4 alongside Xcode 16 and explicitly selected it:

sudo xcode-select -s /Applications/Xcode-15.4.app/Contents/Developer

Verified Xcode selection:

xcode-select -p
# /Applications/Xcode-15.4.app/Contents/Developer

Fully reset Bazel state multiple times:

bazel shutdown
bazel clean --expunge

Attempted explicit Java toolchain registration (resulted in invalid toolchain error)

None of the above resolved the issue.

Additional information

OS: macOS (Apple Silicon, M-series)

Android Studio: Giraffe | 2022.3.1 Patch 4

Android Studio runtime (JBR): 17.0.6 (aarch64)

Java used by Bazel: Embedded remotejdk_11

Repo state: Clean clone

The failure appears to be an upstream incompatibility involving Bazel 6.5.0, the pinned rules_java version, and macOS Darwin toolchains, where @remote_java_tools_darwin is never materialized. Local macOS builds are currently blocked at the toolchain resolution stage.

[adhiamboperes]

Hi @Sandesh282, this is an issue that we experience on Macs that we haven't been able to fully resolve yet. Please see #5791.

My workaround is to open the problem BUILD file by running:

open /private/var/tmp/_bazel_adhiambo/02ee010362edf64cf4a14fbac48cd5cf/external/rules_java/toolchains/BUILD

Then replacing the contents with the ones in the gist below:

https://gist.github.com/adhiamboperes/8a213c84d4127db23ac660ae16e76fa2

The gist is modified to provide the missing tools.

We are currently working on upgrading the project Bazel support to a newer version, and will hopefully have native support for Apple Silicon Macs. Please see #6021.

[Sandesh282]

Thanks for the suggestion, @BenHenning. I tried upgrading rules_java to 5.5.0 (with the correct SHA pinned to the GitHub tag archive), and that did help with the original macOS/Darwin issue (the missing remote_java_tools_darwin error is gone now.)

However, after the upgrade, Bazel 6.5.0 consistently runs into a new problem during toolchain resolution. rules_java_toolchains() appears to auto-register remote JDK toolchains (including JDK 19) for multiple platforms, and Bazel then tries to resolve repos like @remotejdk19_macos_*, @remotejdk19_linux_*, or @remotejdk19_win_*, which aren’t defined in the workspace. Pinning Java via .bazelrc (for example to local_jdk or JDK 17) affects selection, but doesn’t prevent those toolchains from being registered, so the analysis phase still fails.

I also checked whether rules_java_toolchains() supports disabling registration, but in 5.5.0 there doesn’t seem to be an opt-out flag. At the moment, this means the upgrade unblocks the original issue but local builds still get stuck on toolchain resolution, which seems consistent with what’s being tracked in #5791.

Just wanted to share the outcome so you have the full picture of what happens after the upgrade on macOS (Apple Silicon) with Bazel 6.x.

[BenHenning]

Thanks @Sandesh282. Out of curiosity did you get a chance to try the suggestion mentioned here: bazelbuild/rules_java#103 (comment) (per #5791 (comment)). Does that fix the second issue of the remote fetching problem? There's unfortunately no confirmation anyone has tried that yet for Oppia or in the original rules_java issue.

[Sandesh282]

Thanks for the suggestion, @BenHenning. I went ahead and tried the approach based on rules_java#103 in detail, but I wanted to share the outcome since it doesn’t seem to resolve cleanly in Oppia’s setup.

I upgraded rules_java from 5.3.5 → 5.5.0 (with the SHA pinned correctly to the GitHub tag archive). This successfully fixed the original macOS/Darwin issue — the missing @remote_java_tools_darwin error no longer appears.

However, after the upgrade, Bazel 6.5.0 consistently fails during Java toolchain resolution. Specifically, rules_java_toolchains() auto-registers JDK 19 toolchains for multiple platforms (macOS, Linux, Windows), but Oppia’s WORKSPACE does not define the corresponding remotejdk19_* repositories.

I tried applying the workaround discussed in rules_java#103, but in rules_java 5.5.0 the required repository macros do not appear to exist:

• remote_jdk19_repos is not defined
• remote_jdk_repos is not defined
• Only remote_jdk8_repos / remote_jdk11_repos are available

As a result, there doesn’t seem to be a supported way in 5.5.0 to define the repositories needed for the JDK 19 toolchains that are being registered.

Pinning Java via .bazelrc (for example to local_jdk or Java 11/17) affects toolchain selection, but does not prevent these JDK 19 toolchains from being registered, so the analysis phase still fails.

For reference, here is the current error I’m hitting after the upgrade:

ERROR: While resolving toolchains for target //:oppia_dev_binary:
invalid registered toolchain '@remotejdk19_linux_toolchain_config_repo//:toolchain'
The repository '@remotejdk19_linux_toolchain_config_repo' could not be resolved

I also attempted loading the suggested repository macros explicitly, but Bazel reports they are not present in this rules_java version:

Error: file '@rules_java//java:repositories.bzl' does not contain symbol 'remote_jdk_repos'
(did you mean 'remote_jdk8_repos'?)

At this point, it seems that with rules_java 5.5.0 + Bazel 6.x, JDK 19 toolchains are registered unconditionally, but there is no corresponding mechanism in Oppia’s WORKSPACE to define the required repos. This appears consistent with what’s being tracked in #5791.

Just wanted to share the full outcome so you have visibility into what happens after applying the suggested upgrade on my machine.

[BenHenning]

@Sandesh282 you'll need to import remote_jdk19_repos as it should be declared in the same file as rules_java_dependencies (per bazelbuild/rules_java#106). Alternatively that PR landed in 6.0.0. I'm not sure if we can use rules_java 6.0.0 but that's definitely worth a shot (and probably is what you should try first). If 6.0.0 doesn't work with Bazel 6.5.0 or causes some other issue (like an incompatibility with rules_kotlin or rules_proto) then the following should probably work:

Replace the following:

oppia-android/WORKSPACE

Lines 26 to 30 in ed9d8d2

	load("@rules_java//java:repositories.bzl", "rules_java_dependencies", "rules_java_toolchains")
	rules_java_dependencies()
	rules_java_toolchains()

With:

load("@rules_java//java:repositories.bzl", "rules_java_dependencies", "rules_java_toolchains", "remote_jdk19_repos")

rules_java_dependencies()

# TODO: Remove this when it's no longer necessary.
remote_jdk19_repos()

rules_java_toolchains()

(If this works then please file an a feature request issue to migrate the codebase to rules_java 6.0.0 and update the TODO to point to it, e.g. TODO(#1234): Remove this...).

Edit: Did a bit more code archaeology and discovered that the JDK 19 repos were removed shortly after that PR went in with JDK 20 (see bazelbuild/rules_java@f7107b4) so 6.0.0 will actually shift to JDK20. I suspect that will still fix the issue if the codebase is compatible with 6.0.0.

Version 5.5.0 should indeed have the remote_jdk19_repos macro that we need per: https://github.com/bazelbuild/rules_java/blob/dd3361f473d0d3278454de47b30a7fc3605502ed/java/repositories.bzl#L390.

[Sandesh282]

Hi @BenHenning, sorry for the very late reply! I actually came back to this while going through issue #6233 and realized I had never followed up here, so wanted to close the loop properly.

I went ahead and tested 2 approaches:

Approach 1) Your suggestion (rules_java 5.5.0 + remote_jdk19_repos())

This works. After upgrading to 5.5.0 and adding remote_jdk19_repos() between rules_java_dependencies() and rules_java_toolchains() in WORKSPACE (per rules_java#106), the build succeeds cleanly on macOS Apple Silicon with Bazel 6.5.0; no more @remote_java_tools_darwin errors.

The reason my earlier attempt failed was that I was accidentally testing against a version at or after commit f7107b4 (which replaces remote_jdk19_repos with remote_jdk20_repos), so the symbol simply didn't exist in the version I was using at the time.

Approach 2) Jumping directly to rules_java 7.3.1 + rules_jvm_external 6.6

This also works, and has the added benefit of being forward-compatible with Bazel 7 (relevant for #6233). The full set of changes required:

third_party/versions.bzl:

# rules_java: 5.3.5 → 7.3.1
"rules_java": {
    "sha": "4018e97c93f97680f1650ffd2a7530245b864ac543fd24fae8c02ba447cb2864",  # was c73336802...
    "version": "7.3.1",  # was 5.3.5
},
# rules_jvm_external: 5.1 → 6.6
"rules_jvm": {
    "sha": "ec60d258e6f55a1014368e40ca52058b1a645a3d455ca471c4edb7c03f4b8d88",  # was c4cd0fd41...
    "version": "6.6",  # was 5.1
},

WORKSPACE - rules_jvm_external 6.6 requires two setup calls that weren't previously needed:

load("@rules_jvm_external//:repositories.bzl", "rules_jvm_external_deps")
rules_jvm_external_deps()

load("@rules_jvm_external//:setup.bzl", "rules_jvm_external_setup")
rules_jvm_external_setup()

.bazelrc - -Xlint:-options is needed to suppress JDK cross-version compatibility warnings that would otherwise cause javac to error under --javacopt="-Werror":

build --javacopt="-Werror -Xlint:-options" --host_javacopt="-Werror -Xlint:-options"

I tested 5.5.0 mainly to confirm your diagnosis was correct (it was). For the actual upstream fix, I'm thinking the 7.3.1 path makes more sense since it solves the Darwin issue and also serves as groundwork for Bazel 7. I'm planning to pick up #6233 so the rules_java 7.3.1 upgrade would be one of the early migration steps there.

Edit: After reading through the Bzlmod docs, I also realized the root cause of this issue is actually a fundamental WORKSPACE limitation. In WORKSPACE, transitive dependency repos aren't resolved automatically, so when rules_java_toolchains() registers JDK 19/20 toolchains, the repos those toolchains point to still have to be explicitly declared by the consumer (which is what remote_jdk19_repos() is doing manually).

With Bzlmod (#6230), this goes away. rules_java already ships a module extension in java/extensions.bzl that handles JDK repo creation as part of its own toolchain setup. I could actually see this in commit f7107b4 where _toolchains_impl calls remote_jdk20_repos() inside the extension. No manual remote_jdkXX_repos() call needed. So the Bzlmod migration is really the long-term fix here, beyond just the Bazel 7 bump.

[BenHenning]

Thanks @Sandesh282. Glad that works, and I suspect that per approach (2) that #6234 & later branches probably will also fix the issue for you. I hope to merge #6234 soon so the temporary workaround hopefully won't be needed for long (and likely won't be worth actually checking into develop since the more long-term change is actually built).