Skip to content

foojay-resolver-convention 0.5.0 in gradle-plugin is incompatible with Gradle 9.0.0 #56287

Open
Open
foojay-resolver-convention 0.5.0 in gradle-plugin is incompatible with Gradle 9.0.0#56287
Labels
Needs: AttentionIssues where the author has responded to feedback.Needs: ReproThis issue could be improved with a clear list of steps to reproduce the issue.

Description

@brunovmartin
brunovmartin
opened on Mar 31, 2026

Description

The @react-native/gradle-plugin bundles settings.gradle.kts with:

plugins { id("org.gradle.toolchains.foojay-resolver-convention").version("0.5.0") }

React Native 0.83.x uses Gradle 9.0.0 (set in gradle/wrapper/gradle-wrapper.properties), but foojay-resolver-convention 0.5.0 depends on FoojayToolchainsPlugin, a class that was removed in Gradle 9.0.0.

This causes a build failure on any fresh project or after clearing Gradle caches.

Steps to reproduce

npx create-expo-app@latest --template default@sdk-55
cd <project>
rm -rf ~/.gradle/caches
npx expo run:android

Error

FAILURE: Build failed with an exception.

* Where:
Settings file 'android/settings.gradle' line: 21

* What went wrong:
Error resolving plugin [id: 'com.facebook.react.settings']
> org/gradle/toolchains/foojay/FoojayToolchainsPlugin

Full stacktrace:

Caused by: java.lang.NoClassDefFoundError: org/gradle/toolchains/foojay/FoojayToolchainsPlugin
    at org.gradle.toolchains.foojay.FoojayToolchainsConventionPlugin.apply(FoojayToolchainsConventionPlugin.kt:11)

Root cause

Component Version
react-native 0.83.4
@react-native/gradle-plugin 0.83.4
Gradle 9.0.0
foojay-resolver-convention 0.5.0

Gradle 9.0.0 removed the FoojayToolchainsPlugin class that foojay 0.5.0 depends on. Versions 0.8.0+ of foojay-resolver-convention are compatible with Gradle 9.0.0.

Verified fix

Updating settings.gradle.kts in @react-native/gradle-plugin from:

plugins { id("org.gradle.toolchains.foojay-resolver-convention").version("0.5.0") }

to:

plugins { id("org.gradle.toolchains.foojay-resolver-convention").version("0.9.0") }

resolves the issue. The build also requires --no-configure-on-demand to avoid a related metadata.bin generation failure.

Affected versions

  • react-native 0.83.0 through 0.84.1 (all ship foojay 0.5.0 with Gradle 9.0.0)
  • Expo SDK 55 (uses react-native 0.83.x)
  • Reproducible on macOS (ARM64) with Java 17 and Node 24

Environment

System: macOS 26.3.1 (arm64)
Node: v24.14.0
Java: OpenJDK 17.0.18 (Zulu)
Gradle: 9.0.0
react-native: 0.83.4
Expo SDK: 55.0.9

Activity

  1. react-native-bot
    added
    Needs: Author Feedback
    Needs: ReproThis issue could be improved with a clear list of steps to reproduce the issue.
    on Mar 31, 2026

  2. react-native-bot commented on Mar 31, 2026

    @react-native-bot
    react-native-bot
    on Mar 31, 2026
    Collaborator

    Warning

    Missing reproducer: We could not detect a reproducible example in your issue report. Reproducers are mandatory and we can accept only one of those as a valid reproducer:


    You can read more about about it on our website: How to report a bug.

  3. brunovmartin commented on Mar 31, 2026

    @brunovmartin
    brunovmartin
    on Mar 31, 2026
    Author

    Reproducer

    https://github.com/brunovmartin/react-native-foojay-reproducer

    This is a fresh project created with:

    npx create-expo-app@latest --template default@sdk-55

    No modifications. To reproduce:

    git clone https://github.com/brunovmartin/react-native-foojay-reproducer.git
cd react-native-foojay-reproducer
npm install
rm -rf ~/.gradle/caches  # ensure no stale cache masks the bug
npx expo run:android

    The build fails at settings.gradle line 21 with NoClassDefFoundError: org/gradle/toolchains/foojay/FoojayToolchainsPlugin.

    Root cause: @react-native/gradle-plugin@0.83.4 ships settings.gradle.kts with foojay-resolver-convention version 0.5.0, which references a class removed in Gradle 9.0.0. The same @react-native/gradle-plugin ships gradle-wrapper.properties pointing to Gradle 9.0.0, creating an internal incompatibility.

    Fix: Update foojay-resolver-convention from 0.5.0 to 0.9.0 in @react-native/gradle-plugin/settings.gradle.kts.

    This affects react-native 0.83.0 through 0.84.1.

  4. github-actions
    added
    Needs: AttentionIssues where the author has responded to feedback.
    and removed
    Needs: Author Feedback
    on Mar 31, 2026

  5. brunovmartin commented on Mar 31, 2026

    @brunovmartin
    brunovmartin
    on Mar 31, 2026
    Author

    This is a build/upgrade related bug. The reproducer is a project using the official Expo SDK 55 template (npx create-expo-app@latest --template default@sdk-55) with zero modifications:

    https://github.com/brunovmartin/react-native-foojay-reproducer

    This is not reproducible via Snack or RNTesterPlayground since it's a Gradle build-time failure, not a runtime UI bug.

    The issue is purely in @react-native/gradle-plugin's settings.gradle.kts — it ships foojay-resolver-convention version 0.5.0 alongside a gradle-wrapper.properties pointing to Gradle 9.0.0. These two are incompatible: Gradle 9.0.0 removed the FoojayToolchainsPlugin class that foojay 0.5.0 depends on.

    To reproduce:

    git clone https://github.com/brunovmartin/react-native-foojay-reproducer.git
cd react-native-foojay-reproducer
npm install
rm -rf ~/.gradle/caches
npx expo run:android

    One-line fix in @react-native/gradle-plugin/settings.gradle.kts:

    - plugins { id("org.gradle.toolchains.foojay-resolver-convention").version("0.5.0") }
+ plugins { id("org.gradle.toolchains.foojay-resolver-convention").version("0.9.0") }

  6. elijahsanders152-stack commented on Mar 31, 2026

    @elijahsanders152-stack
    elijahsanders152-stack
    on Mar 31, 2026 via email

  7. DHRUV-1000101 commented on Mar 31, 2026

    @DHRUV-1000101
    DHRUV-1000101
    on Mar 31, 2026

    see #56210, it's been resolved. @TheNerdGuyLulu can you also backport it from version 0.82.x to 0.84.x.

  8. xiaoxustudio commented on Apr 18, 2026

    @xiaoxustudio
    xiaoxustudio
    on Apr 18, 2026

    Hey, bro , I'm currently stuck at this step. I found this issue, but I still managed to solve it following the method provided in the issue. I'm not quite sure if it was this plugin that caused the problem.

    npx expo run:android
npm warn Unknown user config "home". This will stop working in the next major version of npm. See `npm help npmrc` for supported config options.
› Opening emulator Pixel_5
› Building app...
Starting a Gradle Daemon (subsequent builds will be faster)
Configuration on demand is an incubating feature.
<-------------> 0% INITIALIZING [15m 54s]
> Evaluating settings > Downloading toolchain from URI https://api.foojay.io/disco/v3.0/ids/69a793dd932268c7d1ae9d8b855
  9. S540d
    added 2 commits that reference this issue on Jul 15, 2026

    chore: expo-Module auf SDK-55-Sollstand + foojay-Gradle-9-Fix (Issue #…

    fbd6386

    Release v1.8.0 (versionCode 69): Mascot, Themen-Packs, Tablet-Layout,…

    4a6b238

  10. react-native-bot commented on Oct 16, 2026

    @react-native-bot
    react-native-bot
    on Oct 16, 2026
    Collaborator

    This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

  11. react-native-bot
    added
    StaleThere has been a lack of activity on this issue and it may be closed soon.
    on Oct 16, 2026

  12. react-native-bot commented on Oct 16, 2026

    @react-native-bot
    react-native-bot
    on Oct 16, 2026
    Collaborator

    This issue is stale because it has been open for 180 days with no activity. It will be closed in 7 days unless you comment on it or remove the "Stale" label.

  13. react-native-bot
    removed
    StaleThere has been a lack of activity on this issue and it may be closed soon.
    on Oct 16, 2026

  14. jivebug commented on Nov 1, 2026

    @jivebug
    jivebug
    on Nov 1, 2026

    Still present in 0.84.1, on bare React Native with no Expo, and I think the
    reason this one keeps getting marked Needs: Repro is worth adding — the bug is
    conditional on the host, not on the project.

    It only fires when Gradle cannot find a JDK 17 locally. Four modules in
    @react-native/gradle-plugin declare kotlin { jvmToolchain(17) }
    (shared, settings-plugin, react-native-gradle-plugin, shared-testutil).
    Gradle counts the JVM it is running on as an available toolchain, so if you
    build on a JDK 17 the request is already satisfied, nothing is provisioned, the
    foojay resolver is never loaded, and everything passes. Build on anything else —
    Android Studio's bundled JBR is 21 — and Gradle tries to auto-provision,
    which loads the pinned foojay-resolver-convention 0.5.0 and fails.

    That is why it reproduces for some people and not others on identical projects.
    Anyone with a JDK 17 on disk cannot reproduce it at all. On macOS it is easy to
    have one and still hit this: a Homebrew openjdk@17 is not linked into
    /Library/Java/JavaVirtualMachines, and Gradle's auto-detection does not scan
    Homebrew's opt prefix, so a perfectly good 17 is invisible and provisioning
    starts anyway.

    A second error signature for the same root cause. This thread reports
    NoClassDefFoundError: org/gradle/toolchains/foojay/FoojayToolchainsPlugin. The
    no-JDK-17 path instead gives a field removal, which names neither RN nor the
    JDK and so is much harder to search for:

    FAILURE: Build failed with an exception.

* What went wrong:
Class org.gradle.jvm.toolchain.JvmVendorSpec does not have member field
'org.gradle.jvm.toolchain.JvmVendorSpec IBM_SEMERU'

BUILD FAILED in 15s

    Reproduced identically on two Apple Silicon machines, macOS 26 and 27, RN
    0.84.1, cd android && ./gradlew help.

    Version requirement, for the record: foojay-resolver-convention 1.0.0
    is the first release that supports Gradle 9 — see
    gradle/foojay-toolchains#151 and gradle/foojay-toolchains#105. RN 0.84.1 pins
    0.5.0 while shipping a gradle-9.0.0-bin.zip wrapper in the plugin itself, so
    the pinned resolver cannot run under the pinned Gradle. (An earlier comment here
    suggests 0.9.0 as a workaround; that is still pre-1.0.0, and per foojay#151 1.0.0
    is the one that actually handles Gradle 9.)

    Workarounds that do not work, in case they save anyone time:

    • org.gradle.java.installations.paths, both as -D and in the app's
      android/gradle.properties — an included build resolves toolchains against its
      own properties, not the consuming build's, so neither reaches the plugin.
    • Downgrading the app's Gradle wrapper — the plugin ships its own 9.0.0 wrapper.

    The only thing that works from outside the plugin is running Gradle on a JDK
    17, so the toolchain request is satisfied and provisioning never happens.

    Flagging that this is stale-labelled with a close warning while still unfixed on
    main: #54160 and #56210 both proposed the 1.0.0 bump and were closed unmerged,
    and #56743 targets 0.83-stable only.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Needs: AttentionIssues where the author has responded to feedback.Needs: ReproThis issue could be improved with a clear list of steps to reproduce the issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions