anchor.diff:  created or modification with a custom `ExpiryPolicy`.
   
   [NOTE]
  -_Expiry after access_ or _time to idle_ is not supported, since it prohibitive to high performance
  -as it is achieved by cache2k. Typically there is no functional requirement for TTI, but it is used
  +_Expiry after access_ or _time to idle_ is not supported, since it would compromise the high performance
  +of cache2k. Typically there is no functional requirement for TTI, but it is used
   very often to minimize memory consumption in times of low activity. How a similar feature can be
   constructed that at the same time is not counter productive for performance needs further research.
   For discussion, see: https://github.com/cache2k/cache2k/issues/39[GH 39]
   
   === Variable Expiry
   
  -Each entry may have a different expiry time. This can be achieved by specifying an `ExpiryPolicy`.
  -The configuration parameter `expireAfterWrite` is used as a maximum value.
  +Each entry may have a different expiry time. This can be achieved by specifying an `ExpiryPolicy`. The `ExpiryPolicy` calculates a point in time, where an entry expires. The configuration parameter `expireAfterWrite` is used as a maximum value.
   
   === Sharp Expiry
   
  
positive.code: 
  === Resetting the Expiry of a Cache Value
  
  The expiry value can be reset with the method `Cache.expireAt(key, time)`. Two special values exist:
  
  .Cache.expireAt constants
  [width="70",options="header"]
  
negative.code: constant,meaning
  Expiry.NOW, The value expires immediately. An immediate load is triggered if refreshAhead is enabled.
  Expiry.REFRESH, An immediate load is triggered if refreshAhead is enabled. If loading is not possible the value expires.
  Expiry.ETERNAL, keep indefinitly or to a maximum of whats set with via `expireAfterWrite`    
  ,===
  
  It is possible to atomically examine a cached entry and update its expiry with the `EntryProcessor` and
  