"Gradle version is incompatible with the Java version" but flutter doctor is all green

[Lars-Hoofs]

Is there an existing issue for this?

• I have searched the existing issues
• I have read the guide to filing a bug

Steps to reproduce

1. Make a project with the command 'Flutter create Name'
2. Open the project in visual studio
3. CD to directory
4. Flutter run

Actual results

The actual result should be that the app displays on my phone

Logs

PS C:\Users\Lars hoofs\Documents\flutter-apps\clocko> flutter run
Launching lib\main.dart on Pixel 6a in debug mode...

FAILURE: Build failed with an exception.

* What went wrong:
Could not open settings generic class cache for settings file 'C:\Users\Lars hoofs\Documents\flutter-apps\clocko\android\settings.gradle' (C:\Users\Lars hoofs\.gradle\caches\7.5\scripts\3d075fs9hjp81ny0sgym4v09w).
> BUG! exception in phase 'semantic analysis' in source unit '_BuildScript_' Unsupported class file major version 64

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 864ms
Running Gradle task 'assembleDebug'...                           1.656ms

┌─ Flutter Fix ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐   
│ [!] Your project's Gradle version is incompatible with the Java version that Flutter is using for Gradle.                                                                                             │   
│                                                                                                                                                                                                       │   
│ To fix this issue, first, check the Java version used by Flutter by running `flutter doctor --verbose`.                                                                                               │
│                                                                                                                                                                                                       │   
│ Then, update the Gradle version specified in C:\Users\Lars hoofs\Documents\flutter-apps\clocko\android\gradle\wrapper\gradle-wrapper.properties to be compatible with that Java version. See the link │   
│ below for more information on compatible Java/Gradle versions:                                                                                                                                        │   
│ https://docs.gradle.org/current/userguide/compatibility.html#java                                                                                                                                     │   
│                                                                                                                                                                                                       │   
│                                                                                                                                                                                                       │   
└───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘   
Exception: Gradle task assembleDebug failed with exit code 1

Flutter Doctor output

Doctor output

C:\Users\Lars hoofs>Flutter doctor -v
[√] Flutter (Channel stable, 3.10.5, on Microsoft Windows [Version 10.0.22621.1928], locale nl-NL)
    • Flutter version 3.10.5 on channel stable at C:\Users\Lars hoofs\Documents\flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 796c8ef792 (4 weeks ago), 2023-06-13 15:51:02 -0700
    • Engine revision 45f6e00911
    • Dart version 3.0.5
    • DevTools version 2.23.1

[√] Windows Version (Installed version of Windows is version 10 or higher)

[√] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at C:\Users\Lars hoofs\AppData\Local\Android\sdk
    • Platform android-34, build-tools 34.0.0
    • Java binary at: C:\Program Files\Common Files\Oracle\Java\javapath\java.exe
    • Java version Java(TM) SE Runtime Environment (build 20.0.1+9-29)
    • All Android licenses accepted.

[√] Chrome - develop for the web
    • Chrome at C:\Program Files\Google\Chrome\Application\chrome.exe

[√] Visual Studio - develop for Windows (Visual Studio Enterprise 2022 17.3.6)
    • Visual Studio at C:\Program Files\Microsoft Visual Studio\2022\Enterprise
    • Visual Studio Enterprise 2022 version 17.3.32929.385
    • Windows 10 SDK version 10.0.19041.0

[√] Android Studio (version 2022.2)
    • Android Studio at C:\Program Files\Android\Android Studio
    • Flutter plugin can be installed from:
       https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
       https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-b2043.56-9586694)

[√] VS Code (version 1.80.0)
    • VS Code at C:\Users\Lars hoofs\AppData\Local\Programs\Microsoft VS Code
    • Flutter extension version 3.68.0

[√] Connected device (4 available)
    • Pixel 6a (mobile) • 28251JEGR15601 • android-arm64  • Android 13 (API 33)
    • Windows (desktop) • windows        • windows-x64    • Microsoft Windows [Version 10.0.22621.1928]
    • Chrome (web)      • chrome         • web-javascript • Google Chrome 114.0.5735.199
    • Edge (web)        • edge           • web-javascript • Microsoft Edge 114.0.1823.79

[√] Network resources
    • All expected network resources are available.

• No issues found!

C:\Users\Lars hoofs>flutter doctor
Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel stable, 3.10.5, on Microsoft Windows [Version 10.0.22621.1928], locale nl-NL)
[√] Windows Version (Installed version of Windows is version 10 or higher)
[√] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
[√] Chrome - develop for the web
[√] Visual Studio - develop for Windows (Visual Studio Enterprise 2022 17.3.6)
[√] Android Studio (version 2022.2)
[√] VS Code (version 1.80.0)
[√] Connected device (4 available)
[√] Network resources

• No issues found!

[Hixie]

cc @reidbaker since this seems similar to recent issues you've looked at

[stuartmorgan]

but flutter doctor is all green

This isn't something that doctor can check for, because the incompatibility is with a project-level setting, not a Flutter-level setting.

Have you followed the instructions in the "Flutter Fix" message in your output?

[reidbaker]

It also might help to use the flutter analyze --suggestions command. I added checks there for AGP and Gradle and Java compatibility.

[Hixie]

I think it's important that if flutter doctor -v is entirely green (no warnings of any kind, no caveats, just all smiles) that flutter create foo; cd foo; flutter run be successful. I don't have strong opinions on exactly how we achieve that.

[gmackall]

I think it's important that if flutter doctor -v is entirely green (no warnings of any kind, no caveats, just all smiles) that flutter create foo; cd foo; flutter run be successful. I don't have strong opinions on exactly how we achieve that.

We may not have project level info in flutter doctor, but we can know the template values. So we could print warnings if we detect that the

1. current Java
2. template AGP
3. template Gradle
   versions will produce a conflict.

[stuartmorgan]

I think it's important that if flutter doctor -v is entirely green (no warnings of any kind, no caveats, just all smiles) that flutter create foo; cd foo; flutter run be successful. I don't have strong opinions on exactly how we achieve that.

Capturing from Discord discussion, my vote would be that we don't go beyond yellow text that says something like:

The version of Java you are using is too new to be compatible with new projects created by flutter create without editing them. To run a new project, you will need to either update the project following the instructions that trying to build it will provide, or install an older version of Java.

Anything we put in doctor for people with newer JDKs will show up for people who have, totally reasonably, updated both Java and the AGP/Gradle versions in their projects, so we need to be very careful that we don't phrase it in a way that would make people who already do have a working setup think they don't (or, even worse, downgrade Java because they think we are telling them to, thus actively breaking their existing, upgraded projects).

[gmackall]

Other ideas are that we could:
-Support a smaller window of java versions (probably lower bounded by the latest required by AGP), and then doctor could detect incompatibility without false negatives for people with newer java versions (because we can use the latest AGP and gradle in the templates).
-Make templates conditional on the java version that flutter will be defaulting to. Again no false negatives, and allows us to keep longer java window of support, but probably not worth the increased complexity.

Also if you have strong feelings on how this relates to #125653, I would appreciate them there 🙂

[stuartmorgan]

-Support a smaller window of java versions (probably lower bounded by the latest required by AGP)

We'd probably want to get stats on JDK versions in use first; actually breaking people just to reduce false positives is a big step unless we believe that the number of affected people is small. (I would like to see use drop some older AGP/Gradle versions based on some of our recent experiences maintaining the full range, but that's about actually reducing our support burden and serious accidental breakages, rather than just doctor output.)

-Make templates conditional on the java version that flutter will be defaulting to. Again no false negatives, and allows us to keep longer java window of support, but probably not worth the increased complexity.

I thought about that, but it's not going to just to just be the versions; we'd then need to make all of the gradle files compatible with the full range, or make all the parts of those be conditional, and that could get very messy very quickly. I guess with enough automated tests to make sure every configuration builds it could be doable...

[reidbaker]

What do we think about running additional code when you run flutter doctor from the root of a flutter project? It breaks the universality but gives us a way to run project specific code evaluation and is a reasonable place for people to try to run the command.

I dont see how we can not check project specific values in futter doctor and have flutter doctor green mean you can build a project.

[Hixie]

we could print warnings if we detect that the

1. current Java
2. template AGP
3. template Gradle
   versions will produce a conflict.

I think that would be a good start.

Obviously making ourselves compatible with a broader range of versions of our dependencies (in particular those we don't pin) would be ideal, but that seems like it would be a disproportionate maintenance and test burden. Another option would be to bring in our own dependency so we could pin it, but that may also be non-trivial compared to just detecting the conflict with our templates and reporting it as an FYI in the output.

[Hixie]

I dont see how we can not check project specific values in futter doctor and have flutter doctor green mean you can build a project.

It doesn't have to mean you can build any project, just that you won't run into trouble if you create a new one and try to run it.

(If it had to report any issue, we'd need to bring in flutter analyze, flutter test, etc, into flutter doctor, which I don't think would lead to a good experience.)

[gmackall]

I also filed #130808 because if this had happened on master the error message would have been confusing in this case (as opposed to how it is here in stable).

[gmackall]

We may not have project level info in flutter doctor, but we can know the template values. So we could print warnings if we detect that the

1. current Java
2. template AGP
3. template Gradle
   versions will produce a conflict.

After thinking more about this, I think doing this in combination with updating our templates to use the latest version of Gradle is the correct solution. My understanding is that our ability to support newer versions of Java is bounded by Gradle's support of newer versions of Java. So if we are always using the latest version of Gradle, we are always supporting as recent a version of Java as we can.

It does mean that if a developer is using stable, and:

1. a new version of Java gets released since last stable cut
2. a new version of Gradle that supports that new version of Java gets released
3. a developer uses that new version of Java and Gradle
   we will print a warning for them, even if everything might actually be working fine.

But I think it is reasonable for us to print a warning that says (with better phrasing) "you are using a newer version of Java than the newest version that Gradle supported at the time of last stable cut, and we can't confirm thats safe to use". It's basically just a flutter doctor check that your Java version isn't newer than we could know about.

[stuartmorgan]

I think doing this in combination with updating our templates to use the latest version of Gradle is the correct solution.

If we start using AGP 8 in the template, people making new projects won't be able to use any plugins that haven't updated to add a namespace. We should seriously consider a period before we do that where we print warnings about plugins that aren't AGP 8 compatible so people have some warning and time to file issues with package authors.

[gmackall]

If we start using AGP 8 in the template, people making new projects won't be able to use any plugins that haven't updated to add a namespace. We should seriously consider a period before we do that where we print warnings about plugins that aren't AGP 8 compatible so people have some warning and time to file issues with package authors.

AGP 8 also requires Java 17. I'm not suggesting AGP 8 though (for that reason and the one you mentioned), only the latest Gradle. The latest Gradle does not require AGP 8 (https://docs.gradle.org/current/userguide/compatibility.html#android)

[stuartmorgan]

👍🏻 Sorry, I misremembered the compat tables and thought the latest Gradle had dropped 7.x. No objection from me to upping the AGP minimum to 7.3 (and I certainly won't miss 4.x).

[camsim99]

It does mean that if a developer is using stable, and:

1. a new version of Java gets released since last stable cut
2. a new version of Gradle that supports that new version of Java gets released
3. a developer uses that new version of Java and Gradle
   we will print a warning for them, even if everything might actually be working fine.

But I think it is reasonable for us to print a warning that says (with better phrasing) "you are using a newer version of Java than the newest version that Gradle supported at the time of last stable cut, and we can't confirm thats safe to use". It's basically just a flutter doctor check that your Java version isn't newer than we could know about.

To follow up on the solution that @gmackall proposed, one way we could try to mitigate 3 is instead of adding the warning to flutter doctor, adding it to flutter create because at that point of development, we know that the developer would be using the template Gradle version, and we can show the warning based on their configured Java version. We could also consider adding the warning to flutter create in addition to flutter doctor with maybe the former being red, the latter being yellow (or something of the like) to acknowledge the fact that the developer might have fixed it on their own after creating a project.

[reidbaker]

That is a genuinely clever thought @camsim99. I think that would align with Ian's statement flutter create foo; cd foo; flutter run should work. #130515 (comment)

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

[camsim99]

This issue should philosophically be solved by #131444, but I will continue to work in this area of the Flutter tool to address #134780 and test out that cleanup work and the effectiveness of the warning that I added by eventually addressing #135022.