I just tested on Mac OS X and here the automatic inclusion of classes.jar seems to work. It's therefore probably a bug that it doesn't on Linux (Ubuntu 10.04 64bit, Oracle 1.6.0_24-b07)

Demo project to demonstrate the problem.

$ gradle compileJava

fails to compile the source file under Ubuntu. Uncommenting the dependency makes it work. Seems to work out-of-the-box on Mac OS X

I ran into this problem indirectly when trying to use Lombok in a mixed Java-Groovy project; groovyc can't seem to use Lombok as an annotation processor on Linux, even though pure Java projects can use Lombok without any problems (also the classes in src/main/java which use Lombok inside a Groovy project compile fine).

EDIT: I managed to work around this by not forking the groovy compiler with the line:

tasks.compileGroovy.groovyOptions.fork=false

Now it works both on OSX and Linux.

We are currently trying to migrate http://asdoclet.fluffnstuff.org/ to gradle and can't because that framework uses the JavaDoc classes inside tools.jar a lot, so that issue here is a show-stopper for us.

@Marco: Mac OS has no tools.jar, it is included automatically.

@Klaus: You can add tools.jar yourself, with something like:

dependencies {
  compile files("${System.getProperty('java.home')}/lib/tools.jar")
}

On Mac OS X 'tools.jar' is named 'classes.jar', and it is indeed included automatically. But it is Ubuntu where the default behavior fails me as the attached example tries to demonstrate.

Against which Gradle version(s) did you try the sample project? Thanks.

I didn't try the sample project. Did you try to add the tools Jar as shown above?

I only reported this issue, because my project did not build without custom changes. I did not rate this problem as a show-shopper. I've used similar code like you as a workaround.

I for one would appreciate if building on Linux would work just like on other platforms - without having to apply custom code. 'includeJavaRuntime' simply did not work as advertised. I haven't tested with the most recent milestones. Thanks.

Peter, for what its worth we just ran into this for the Hibernate build and what you suggested worked for us. The build was running on Mac OS, this got it running on Linux, no idea about Windows.

So I'm encountering a slightly related issue.

I'm using a 3rd party library that creates a JavaDoc/Doclet so it needs `tools.jar`.

However, the library source uses Java 7's JavaDoc API. The JavaDoc API was changed in Java 8. I have Java 8 installed on my system.

When I use the following in my `build.gradle` file:
compile files("${System.properties['java.home']}/../lib/tools.jar")

This is the path it resolves to:
/Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home/jre/../lib/tools.jar

which then causes a compilation error due to mismatched APIs.

Is there any way to handle this situation? The only way I can think of overcoming it is to manually copy the `tools.jar` Java 7 Version into a `lib` folder and just include it with:
fileTree(dir: 'lib', include: '*.jar')

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.