Android build fails if there is a Java version on the path
- Dominant language
- Python
- Stars
- 3.3k
- Forks
- 549
- Avg merge
- 1d 4h
- Merged PRs (30d)
- 40
Description
If there is a version of Java referenced in the `PATH`, it is used in preference to the location described by `JAVA_HOME`. As a result, if that Java version is incompatible with the Android tools (Oracle Java 17 is apparently incompatible with Android), this will cause Android builds to fail.
Reported via #671.
**To Reproduce**
Steps to reproduce the behavior:
1. Set `JAVA_HOME` to `C:\Program Files\Java` (But don't install Java at this location)
2. Install Oracle Java 17, ensuring that `C:\Program Files\Common Files\Oracle\Java\javapath` ends up in your `PATH`
3. Generate a hello world project
4. `briefcase run android`
5. See error
```
FAILURE: Build failed with an exception.
* What went wrong:
A problem occurred configuring project ':app'.
> java.lang.NullPointerException
* 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 8m 12s
Error while building project.
```
**Expected behavior**
Android project should run successfully.
**Environment:**
- Operating System: Windows (may be reproducible on other operating systems)
- Python version: Any
- Software versions:
- Briefcase: 0.3.8
**Additional context**
The original report had an interesting presentation. `JAVA_HOME` was set, but *not* set to a valid Java location. Oracle Java 17 was also installed, and this version was in the PATH.
The Java verification is based on trying to invoke `%JAVA_HOME%/bin/javac -version`; this fails, so Briefcase downloads it's own version of Java and installs it in `~/.briefcase/tools/java`.
However, a bare `javac` *does* work, executing the Oracle Java version installed at `C:\Program Files\Common Files\Oracle\Java\javapath`.
Briefcase passes `JAVA_HOME` into the environment (pointing at the Briefcase version), but *doesn't* modify the `PATH`. In this environment, when Gradle invokes `javac`, it appears that Gradle finds the Oracle version of Java, which breaks the build with the null pointer error.
It's not clear if the `JAVA_HOME`-ignoring is a Windows behavior, or a Gradle behavior.
There are two pieces required by a the fix:
1) Verify `javac -version` before verifying `%JAVA_HOME%/version`
2) Insert `JAVA_HOME` into the `PATH` when invoking gradle.
The first ensures that `javac` (as invoked by gradle) is a valid Java version; the second ensures that the valid version found by briefcase (either Briefcase provided, or user installed) takes priority on the path.
In the meantime, the workaround is to ensure that there isn't a java version in the path.
Contributor guide
Assessment
This issue has not been assessed yet.