Normalize Java SDK (JDK) location logic across the tool #124233
Normalize Java SDK (JDK) location logic across the tool #124233auto-submit[bot] merged 5 commits intoflutter:masterfrom
Conversation
|
This is (technically) a breaking change since the version of Java found by Unrelated FYI for @reidbaker: this change shouldn't block (or risk merge conflicts with) any other work surrounding #122376. I'll save any refactoring for once the critical work is done. Footnotes
|
|
Solid this will get a review today as soon as I am out of meetings |
gnprice
left a comment
There was a problem hiding this comment.
Looks good to me.
I think a refactor like #124152 is important in order to prevent the two implementations of which JDK to use from diverging again in the future. But this fix makes sense as a way of reconciling the behavior for now while minimizing conflicts with related urgent changes.
In addition to filing that tech-debt issue, I'd suggest adding a couple of comments about the need to keep these separate implementations in sync.
| @@ -426,22 +426,6 @@ class AndroidSdk { | |||
| return fileSystem.path.join(javaHomeEnv, 'bin', 'java'); | |||
| } | |||
There was a problem hiding this comment.
It'd be good to add a comment at the top of this function saying it needs to be kept in sync with how android/gradle.dart sets JAVA_HOME when running Gradle.
Also a comment at the relevant places in that file (the two places that https://github.com/flutter/flutter/pull/124152/files#diff-3c44d2e8279ea8d917b4fb942252d4649689154c36cf74227a1a2a879aaf1915 changes to use _javaSdkHome) saying they need to be kept in sync with what findJavaBinary does.
christopherfujino
left a comment
There was a problem hiding this comment.
LGTM, but I'll leave final approval to @reidbaker
Normalize Java SDK (JDK) location logic across the tool
Fixes #122609.
Related: #122376
Context
flutter doctor -vprints the path of thejavabinary that one might assume to be used for all Android-related features (building apps using Gradle, managing emulators, etc.). However, thisjava-locating logic is different than that used specifically when building Android apps using Gradle. See discussions on #122609 for more info.To summarize:
For most activities, including
flutter doctorvalidators and Android SDK-related features (creating emulators, checking license acceptance, etc..), we use the following logic:JAVA_HOME(from env) if it is set; otherwise/usr/libexec/java_home -v 1.8if any; otherwisewhich java(search forjavaon PATH)However, specifically when building Android apps using Gradle,
/usr/libexec/java_home(step 3) will never be consulted. Instead, we'll explicitly setJAVA_HOMEto the Android Studio-bundled JDK if it exists; otherwise,gradlewwill implicitly consultJAVA_HOMEand then look forjavaon PATH.This has the potential to be confusing to those debugging build issues in Android-enabled flutter projects.
Change
We'll stop using
/usr/libexec/java_home -v 1.8as a second-to-last fallback for non-Gradle build activities.Pre-launch Checklist
Pre-launch Checklist
///).