The logic used to find a JDK in various tool operations is unclear and confusing #124252
Description
Investigation into #122609 revealed that the logic used to to find a java binary for Java-dependent activites was inconsistent across those activities. For more about that logic and how it was inconsistent, see this comment from #122600. While this issue was fixed by making the implementations of Java-finding logic consistent across the tool, this consistency is fragile; because these implementations exist independently of each other. This also isn't the first time this has been noticed (see #9429).
The tool code should be refactored to 1) make JDK-finding logic as explicit as possible1 and 2) make JDK-finding logic as consistent as possible. This should reduce the chance of future confusion and/or introduction of bugs.
Tangentially related: #121501, #106416
Footnotes
-
For example,
gradlewand Android SDK tools (such asavdmanagerandsdkmanager) look for Java by first consultingJAVA_HOMEon the environment and thenjavaon the path. When invoking those tools, the flutter tool will setJAVA_HOMEto the path of the Android Studio-bundled JDK if it exists. This means that the order in which we look for the JDK for these operations is 1) the Android-Studio bundled JDK, 2)JAVA_HOME, and then 3)javaon PATH (which java). However, the existence of 2 and 3 is not obvious to those reading only the flutter tool code. ↩