anchor.diff:  support, the caching abstraction allows consistent use of various caching solutions with
   minimal impact on the code.
   
  -As from Spring 4.1, the cache abstraction has been significantly extended with the
  -support of <<cache-jsr-107,JSR-107 annotations>> and more customization options.
  +In Spring Framework 4.1, the cache abstraction was significantly extended with support
  +for <<cache-jsr-107,JSR-107 annotations>> and more customization options.
   
   
   
  
positive.code: === Plugging-in Different Back-end Caches
  
  Clearly, there are plenty of caching products out there that you can use as a backing
  store. For those that do not support JSR-107 you need to provide a `CacheManager` and a `Cache` implementation.
  This may sound harder than it is, since, in practice, the classes tend to be simple
  https://en.wikipedia.org/wiki/Adapter_pattern[adapters] that map the caching abstraction
  framework on top of the storage API, as the `ehcache` classes do. Most `CacheManager`
  classes can use the classes in the `org.springframework.cache.support` package
  (such as `AbstractCacheManager` which takes care of the boiler-plate code,
  leaving only the actual mapping to be completed). We hope that, in time, all relevant caches will offer JSR-107 support.
  
  
  
  
negative.code: === JCache (JSR-107) Annotations
  
  Since version 4.1, Spring's caching abstraction fully supports the JCache standard
  (JSR-107) annotations: `@CacheResult`, `@CachePut`, `@CacheRemove`, and `@CacheRemoveAll`
  as well as the `@CacheDefaults`, `@CacheKey`, and `@CacheValue` companions.
  You can use these annotations even without migrating your cache store to JSR-107.
  The internal implementation uses Spring's caching abstraction and provides default
  