Spring Tool Suite
  1. Spring Tool Suite
  2. STS-2276

The Gradle task launcher does not repect the JAVA_HOME environment variable

    Details

    • Type: Bug Bug
    • Status: Resolved Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.8.0.RELEASE
    • Fix Version/s: 3.0.0.M1
    • Component/s: GRADLE
    • Labels:
      None

      Description

      I know that once STS-2213 is implemented this would be simpler to address. However, the current situation seems to have a foundamental problem.

      Working in Windows 7 64-bit with 64-bit Eclipse. eclipse.ini specifies the parameter -vm "C:/Program Files/Java/jre6/bin/javaw.exe" (this is a JRE), while the JAVA_HOME environment variable is set to "C:\Program Files\Programmazione\Java\jdk1.6.0_22" (this is a JDK).

      When I try to run a Gradle task with the External Tools Configuration, I get the following incoherent output:

      [sts] -----------------------------------------------------
      [sts] Starting Gradle build for the following tasks: 
      [sts]      :prepareAppletsForEclipse
      [sts] JAVA_HOME is set to 'C:\Program Files\Programmazione\Java\jdk1.6.0_22'
      [sts] -----------------------------------------------------
      [...]
      :MyProject:compileJava
      FAILURE: Build failed with an exception.
      
      * What went wrong:
      Execution failed for task ':MyProject:compileJava'.
      Cause: Unable to find a javac compiler;
      com.sun.tools.javac.Main is not on the classpath.
      Perhaps JAVA_HOME does not point to the JDK.
      It is currently set to "C:\Program Files\Java\jre6"
      

      So, while it first says that the JAVA_HOME is set correctly, once it has to start compiling it complains it is not, because it seems like it's using the "-vm" Eclipse command line argument to resolve the Java location instead of the JAVA_HOME environment variable.

      This said, if I try to remove the JAVA_HOME environment variable and start Eclipse with a JDK (specifying -vm "C:\Program Files\Programmazione\Java\jdk1.6.0_22" command line argument, so overriding what's specified in the eclipse.ini), I get the following output:

      [sts] -----------------------------------------------------
      [sts] Starting Gradle build for the following tasks: 
      [sts]      :prepareAppletsForEclipse
      [sts] JAVA_HOME is NOT SET
      [sts] -----------------------------------------------------
      [...]
      :MyProject:compileJava
      
      FAILURE: Build failed with an exception.
      
      * What went wrong:
      Execution failed for task ':MyProject:compileJava'.
      Cause: Unable to find a javac compiler;
      com.sun.tools.javac.Main is not on the classpath.
      Perhaps JAVA_HOME does not point to the JDK.
      It is currently set to "C:\Program Files\Java\jre6"
      

      (plase note that I've checked that the -vm argument was taken up correctly by Eclipse, by looking at Help | About Eclipse Platform | Installation Details | Configuration)

      This makes me wonder where the hell is the daemon taking that value for the JAVA_HOME environment variable... The only thing I can think of is that my system-wide registered JRE (i.e.: the one that is launched if I open a Command Prompt and type "java -version") is located in "C:\Program Files\Java\jre6" and that the Gradle daemon is taking this by looking at the java.home system property returned by that Java instance.

      So I'm stuck, I don't know how to make Gradle compile when launched from within Eclipse...

        Activity

        Hide
        Mauro Molinari added a comment -

        I moved the discussion at: http://forum.springsource.org/showthread.php?131138-quot-Use-Gradle-wrapper-s-default-quot-meaning
        Since it's off topic here. Thanks in advance.

        Show
        Mauro Molinari added a comment - I moved the discussion at: http://forum.springsource.org/showthread.php?131138-quot-Use-Gradle-wrapper-s-default-quot-meaning Since it's off topic here. Thanks in advance.
        Hide
        Carlo Luib-Finetti added a comment -

        Yesterday I prepared a presentation on Gradle and STS Gradle plugin and used some small demo project.

        First, on my computer I stumbled over the error from above "Unable to find a javac compiler;". Then, on the machine of my collegue, to which I copied my Eclipse installation and the demo projects, another strange error happened. On trying to import the Gradle projects, a error dialog box appeared saying something like that: "cannot create JVM - not enough heap space"!

        Then, on my computer I tried to fight the problem by giving the Gradle project a "gradle.properties" file with these contents:

        • org.gradle.daemon=false
        • org.gradle.java.home=D:/java/jdk1.7

        After reloading the project in Eclipse everything worked like it should. So, on the machine of my collegue, I did the same thing, copying the "gradle.properties" to the project directory. After restart of Eclipse, we could import the Gradle project without any error.

        Maybe this helps you with your probs.

        Show
        Carlo Luib-Finetti added a comment - Yesterday I prepared a presentation on Gradle and STS Gradle plugin and used some small demo project. First, on my computer I stumbled over the error from above "Unable to find a javac compiler;". Then, on the machine of my collegue, to which I copied my Eclipse installation and the demo projects, another strange error happened. On trying to import the Gradle projects, a error dialog box appeared saying something like that: "cannot create JVM - not enough heap space"! Then, on my computer I tried to fight the problem by giving the Gradle project a "gradle.properties" file with these contents: org.gradle.daemon=false org.gradle.java.home=D:/java/jdk1.7 After reloading the project in Eclipse everything worked like it should. So, on the machine of my collegue, I did the same thing, copying the "gradle.properties" to the project directory. After restart of Eclipse, we could import the Gradle project without any error. Maybe this helps you with your probs.
        Hide
        Kris De Volder (c) added a comment -

        Carlo that is interesting. I am a bit puzzled however. As far as I know the tooling api will always use the gradle daemon to connect to a target Gradle distribution. Does adding this property in fact stop the daemon and run gradle in the same JVM process as your STS Eclipse? (To answer this question, you can try running 'jps' on the commandline to check if a 'GradleDaemon' process is present).

        If it does stop the daemone then I think setting properties like "org.gradle.java.home=D:/java/jdk1.7" is really useless since it will then automatically be using the same JVM as the host eclipse process?

        Assuming that both properties are actually meaningful and respected by the tooling api... I think it is really impossible that they both be respected at the same time.

        Anyhow... I am still glad it solved your problem however

        And it is certainly also possible I'm completely wrong about how these properties work.

        Show
        Kris De Volder (c) added a comment - Carlo that is interesting. I am a bit puzzled however. As far as I know the tooling api will always use the gradle daemon to connect to a target Gradle distribution. Does adding this property in fact stop the daemon and run gradle in the same JVM process as your STS Eclipse? (To answer this question, you can try running 'jps' on the commandline to check if a 'GradleDaemon' process is present). If it does stop the daemone then I think setting properties like "org.gradle.java.home=D:/java/jdk1.7" is really useless since it will then automatically be using the same JVM as the host eclipse process? Assuming that both properties are actually meaningful and respected by the tooling api... I think it is really impossible that they both be respected at the same time. Anyhow... I am still glad it solved your problem however And it is certainly also possible I'm completely wrong about how these properties work.
        Hide
        Carlo Luib-Finetti added a comment -

        Interesting: you're right Kris. Just started Eclipse on my demo project, ran the "build" task, then called "jps" which shows "2756 GradleDaemon".

        Ok, to verify, I shut down Eclipse, killed the daemon process, set the property "true", restartet Eclipse, built the project, and saw the daemon process. Repeated, this time with property set to "false". Same results: the daemon is started.

        But notice, what I've done just now was on my computer at home; what I reported before was on my computer at work (same OS, same JDK, same Gradle, same Eclipse/STS, although).

        somehow, very confusing -

        Show
        Carlo Luib-Finetti added a comment - Interesting: you're right Kris. Just started Eclipse on my demo project, ran the "build" task, then called "jps" which shows "2756 GradleDaemon". Ok, to verify, I shut down Eclipse, killed the daemon process, set the property "true", restartet Eclipse, built the project, and saw the daemon process. Repeated, this time with property set to "false". Same results: the daemon is started. But notice, what I've done just now was on my computer at home; what I reported before was on my computer at work (same OS, same JDK, same Gradle, same Eclipse/STS, although). somehow, very confusing -
        Hide
        Kris De Volder (c) added a comment -

        Ok, well, it's less confusing if you know that tooling API is simply hardwired to use the daemon. I think that's simply how it is able to connect to different target distributions than the host tooling API version. To do that it needs to run the target gradle in a separate JVM.

        It could be that the "org.gradle.java.home=D:/java/jdk1.7" property is what makes things work for you.

        If so, I think it should also work if you set the Java home via the Gradle preferences page in STS.

        Show
        Kris De Volder (c) added a comment - Ok, well, it's less confusing if you know that tooling API is simply hardwired to use the daemon. I think that's simply how it is able to connect to different target distributions than the host tooling API version. To do that it needs to run the target gradle in a separate JVM. It could be that the "org.gradle.java.home=D:/java/jdk1.7" property is what makes things work for you. If so, I think it should also work if you set the Java home via the Gradle preferences page in STS.

          People

          • Assignee:
            Kris De Volder (c)
            Reporter:
            Mauro Molinari
          • Votes:
            1 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              First Response Date: