anchor.diff:  
   Starting with Gradle 2.1, it is possible to compile Java incrementally. See the api:org.gradle.api.tasks.compile.JavaCompile[] task for information on how to enable it.
   
  -Main goals for incremental compilations are: 
  +Main goals for incremental compilations are:
   
   * Avoid wasting time compiling source classes that don't have to be compiled. This means faster builds, especially when a change to a source class or a jar does not incur recompilation of many source classes that depend on the changed input.
   * Change as few output classes as possible. Classes that don't need to be recompiled remain unchanged in the output directory. An example scenario when this is really useful is using JRebel - the fewer output classes are changed the quicker the JVM can use refreshed classes.
  - The incremental compilation at a high level: 
  +
  +The incremental compilation at a high level:
   
   * The detection of the correct set of stale classes is reliable at some expense of speed. The algorithm uses bytecode analysis and deals gracefully with compiler optimizations (inlining of non-private constants), transitive class dependencies, etc. Example: When a class with a public constant changes, we eagerly compile classes that use the same constants to avoid problems with constants inlined by the compiler.
   * To make incremental compilation fast, we cache class analysis results and jar snapshots. The initial incremental compilation can be slower due to the cold caches.
  -  
   
   [[sec:incremental_compilation_known_issues]]
   ==== Known issues
  
positive.code: 
  Gradle can only run on Java version 7 or higher. Gradle 3.x still supports compiling, testing, generating Javadoc and executing applications for Java 6. Java 5 is not supported.
  
  To use Java 6 the following tasks need to be configured: 
  
  * `JavaCompile` task to fork and use the correct Java home
  * `Javadoc` task to use the correct `javadoc` executable
  * `Test` and the `JavaExec` task to use the correct `java` executable.
   The following sample shows how the `build.gradle` needs to be adjusted. In order to be able to make the build machine-independent, the location of the Java 6 home should be configured in `GRADLE_USER_HOME/gradle.properties` footnote:[For more details on `gradle.properties` see <<sec:gradle_configuration_properties>> ] in the users home directory on each developer machine, as shown in the example. 
  ++++
  <sample xmlns:xi="http://www.w3.org/2001/XInclude" id="javaCrossCompilation" dir="java/crossCompilation" title="Configure Java 6 build">
                  <sourcefile file="gradle.properties"/>
                  <sourcefile file="build.gradle" snippet="java-cross-compilation"/>
              </sample>
  ++++
   
negative.code: * If a compile task fails due to a compile error, it will do a full compilation again the next time it is invoked.
  * Because of type erasure, the incremental compiler is not able to recognize when a type is only used in a type parameter, and never actually used in the code. For example, imagine that you have the following code: `List&lt;? extends A&gt; list = Lists.newArrayList();` but that no member of `A` is in practice used in the code, then changes to `A` will not trigger recompilation of the class. In practice, this should very rarely be an issue.
  
  
  
  [[sec:java_compile_avoidance]]
  === Compile avoidance
  
  If a dependent project has changed in an https://en.wikipedia.org/wiki/Application_binary_interface[ABI]-compatible way (only its private API has changed), then Java compilation tasks will be up-to-date. This means that if project `A` depends on project `B` and a class in `B` is changed in an ABI-compatible way (typically, changing only the body of a method), then Gradle won't recompile `A`.
  
  Some of the types of changes that do not affect the public API and are ignored:
  
  * Changing a method body
  * Changing a comment
  