jfxRun will not run app using JAVA_HOME if it's not the default.

[StrangeNoises]

I started out writing this as a Java 9 bug, but it affects any Java version. The short version:

The jfxRun task by default (useEnvironmentRelativeExecutables = true) will always run the project using the java binary in $PATH, regardless of whether it has been launched with JAVA_HOME pointing at a different JDK.

If you set useEnvironmentRelativeExecutables = false the path to the Java executable is constructed under the assumption that the "java.home" system property points to the jre directory inside JAVA_HOME. It tries then to point to a bin directory inside the parent directory of "java.home".

This becomes more visible in Java 9ea, because, at least on Linux, there is no such jre subdirectory, and "java.home" will normally be pointing at the actual JDK home. So there will be no bin directory in the parent of that Java Home directory.

But you can also persuade this to happen with Java 8. So for instance you can do:

# Set default java to some other JVM.
JAVA_HOME=/usr/lib/jvm/java-8-oracle gradle jfxRun

Assuming it runs, if you have your program output the version/home of the jvm it's running in, you'll see it's the default one, or it fails to find a java binary at all, depending on useEnvironmentRelativeExecutables being true or false. In my case, as I was successfully building in Java 9, the failure mode was that Java 8 couldn't run the application because of it's too-new class file version, which made the error very obvious.

This behaviour is hard-coded in JfxAbstractWorker.java in getEnvironmentRelativeExecutablePath(boolean). The problem is, at least in the 9ea versions, this is making an unwarranted assumption about the location and layout of Java Home. There is no jre subdirectory, and even if there is, the system property java.home does not necessarily point to it, but instead is already pointing to the right place, in this case /usr/lib/jvm/java-9-oracle or /usr/lib/jvm/java-8-oracle. Going to its parent and to a bin directory in there is therefore doomed to fail.

I think rather than put version number checks, in a more behavioural check would be to check if the path returned by java.home ends in "jre", and only do the current behaviour if it does. Something like:

String jdkPath = jrePath + File.separator
    + (jrePath.endsWith("jre") ? ".." + File.separator : "")
    + "bin" + File.separator;

I think that would then allow

JAVA_HOME=/usr/lib/jvm/java-9-oracle gradle jfxRun

to work as expected when JAVA_HOME is not the default version.

(edits to fix typos, that only become visible upon submitting the issue!)

[FibreFoX]

Thanks for reporting this issue. The assumption was made, because you need the JDK being installed. The java.home-property does point to the JRE, in the case of gradle running with the JDK, this points to the JRE inside the JDK, this is official behaviour. This is documented at least here: http://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html

As the plugin does NOT have proper JDK 9 support yet (I'm already working on that support since a long time, but due to this being a spare time project, I lack behind my own plans).

I will hold this issue open, even this could be closed in favor of #57

[FibreFoX]

Even having JDK 9 compatibility (see #57 (comment) ), this bug is not yet fixed (sorry, forgot about this)

[FibreFoX]

I will close this, as this is not feasible, due to mixing JDKs, which itself would end up incompatible. It requires to use the JDK used by Gradle.