This is still an issue in 1.0-milestone-2.
Another idea I had for making this better is that it would be nice to define the CLASSPATH variable in an external file and then have the run script load it. That way if I want to create my own run script it's easier to have it use the same classpath.

If you don't set JAVA_HOME, the script will use the 'java' command from your PATH.

Effectively, all the garbage in the script does is `which java`. We should certainly clean it up to simplify the logic, but if we did so, there wouldn't be any actual change in behaviour. The script would use $JAVA_HOME/bin/java if set, otherwise `which java`.

@Ben, you can do this sort of thing already, without needing to change the scripts. Here's an example:

task classpathVar {
    def outputFile = file("${startScripts.outputDir}/classpath.sh")
    // These 2 make the task incremental
    outputs.file outputFile
    inputs.files startScripts.classpath
    // Generate the classpath script
    doLast {
        def classpath = startScripts.classpath.collect { "lib/${it.name}" }.join(':')
        outputFile.text = "CLASSPATH=$classpath"
    }
}

startScripts.dependsOn classpathVar

It wasn't working for me despite having java on my path. Perhaps part of the problem is that it does 'which javac' instead of 'which java'. I compiled on one machine which had a JDK and then deployed on another which had only a JRE. Is there any reason it needs a JDK? Could it be changed to actually do 'which java' instead of 'which javac'? Thanks for the help!

I think "which javac" is a bug. It should be "which java" imho. I'll recheck this soon.

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.