anchor.diff:  
   | Tracking the Java vendor implementation
   | Gradle currently tracks the major version of Java that is used for compilation and test execution. If your build uses several Java implementations (IBM, OpenJDK, Oracle, etc) that are the same major version, Gradle will treat them all as equivalent and re-use outputs from any implementation.
  -| Only enable caching for builds that all use the same Java implementation or manually add the Java vendor as an input to compilation and test execution tasks.
  +| Only enable caching for builds that all use the same Java implementation or manually add the Java vendor as an input to compilation and test execution tasks by using <<sec:task_input_output_runtime_api,the runtime api>> for adding task inputs.
   
   | Tracking the Java version
   | Gradle currently tracks the major version of Java (6 vs 7 vs 8) that is used for compilation and test execution. If your build expects to use several minor releases (1.8.0_102 vs 1.8.0_25), Gradle will treat all of these as equivalent and re-use outputs from any minor version. In our experience, bytecode produced by each major version is functionally equivalent.
  
positive.code: 
  
  [[sec:build_cache_known_issues]]
  === Known Issues with built-in Build Caches
  
  The built-in build caches have some known issues which will be addressed in future releases.
  
  
negative.code: Beyond incremental builds described in <<sec:up_to_date_checks>>, Gradle can save time by reusing outputs from previous executions of a task by matching inputs to the task.
  Task outputs can be reused between builds on one computer or even between builds running on different computers via a build cache.
  
  For an initial release, we have focused on the use case where users have an organization-wide remote build cache that is populated regularly by continuous integration builds.
  Developers and other continuous integration agents should pull cache entries from the remote build cache.
  We expect that developers will not be allowed to populate the remote build cache, and all continuous integration builds populate the build cache after running the `clean` task.
  
  