gradle idea incorrectly fails with JAVA_HOME not set

[alpar-t]

user @doubleuhy notes that:

gradle idea

Where:
Build file '/Users/zhouwuhong/elasticsearch/benchmarks/build.gradle' line: 31

What went wrong:
A problem occurred evaluating project ':benchmarks'.

Failed to apply plugin [id 'elasticsearch.build']
JAVA_HOME must be set to build Elasticsearch

but

echo $JAVA_HOME
/Library/Java/JavaVirtualMachines/jdk-10.jdk/Contents/Home

I have seen this in the past, including on SO. I think what happens is that importing the project from idea without running ./gradlew idea first creates a daemon that is not restarted when running ./gradlew idea from the command line with the env var set despite there being a different env.

Running ./gradlew --stop makes the problem go away.

[elasticmachine]

Pinging @elastic/es-core-infra

[alpar-t]

just saw this in the Gradle dameon log:

09:33:08.432 [WARN] [org.gradle.launcher.daemon.server.exec.EstablishBuildEnvironment] Warning: Unable able to set daemon's environment variables to match the client because:
  Java 9 does not support modifying environment variables.
  If the daemon was started with a significantly different environment from the client, and your build
  relies on environment variables, you may experience unexpected behavior.

Which comes from gradle/gradle#2159

[alpar-t]

I don't think that there's much we can do about that.
I really think Gradle shouldn't be so silent about this, and start a new daemon.
The best we can do is to update the error message we throw when no JAVA_HOME is set to have a note about this behavior, maybe link to this issue.

[alpar-t]

@rjernst, why are we requiring the env var in the first place? Is it because we run stuff as part of the tests that require it ? Would it be better to pass it explicitly in these cases ?

[rjernst]

There are a couple of reasons we require JAVA_HOME:

• Ensures the user is explicitly telling us which java to build with. We've had many problems in the past where a contributor was using a different version of java than they realized because one was on the PATH earlier than another.
• Makes it easier to quickly switch between java versions by setting the env var, instead of changing PATH. This was more important before we could trust --release in java to compile against a different version specification/libs.