According to p.1 "API changes require discussion, use cases, etc. Code comes later.", I'm going to start discussion about benefits of proposed changes. 

Now com.google.common.cache.CacheBuilder contains such methods as
`refreshAfterWrite(long duration, TimeUnit unit)`
`expireAfterWrite(long duration, TimeUnit unit)`
`expireAfterAccess(long duration, TimeUnit unit)`
Parameters of methods listed below are used to define durations in time.
However, in Java 8 new class,  [java.time.Duration](https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html), was presented. It can be used to save info about time durations in exactly one object. That is easier and more transparent in some real-world scenarios. 

The idea is to add overloaded methods:
`refreshAfterWrite(Duration duration)
expireAfterWrite(Duration duration)
expireAfterAccess(Duration duration)`

Proposed changes provide possibilities to simplify code:
`expireAfterWrite(Duration.ofHours(3))
// instead of
expireAfterWrite(3, TimeUnit.HOURS)
`
It makes easier to declare constant durations too:

`public static final Duration EXPIRES_IN = Duration.ofHours(1);
// some code after statement
expireAfterWrite(EXPIRES_IN)
`
instead of
`public static final long DURATION_LENGTH = 1;
 public static final TimeUnit DURATION_TIME_UNIT = TimeUnit.HOURS;
 // some code after statement
 expireAfterWrite(DURATION_LENGTH, DURATION_TIME_UNIT)
`

Also, it allows to execute some arifmetic operations like addition or subtraction, that can simplify program logic if multiple (and dependant) durations in different methods and/or in different caches are used. Just something like this (simplified synthetic example):
`
Duration expiresAfterAccessIn = Duration.ofMinutes(30);
CacheBuilder.newBuilder()
                    .expireAfterAccess(expiresAfterAccessIn)
                    .expireAfterWrite(expiresAfterAccessIn.plusHours(1))
                    .build();
`

This improvements do not lead to changing min java sdk version and do not break existing API.
/**
   * Specifies a listener instance that caches should notify each time an entry is removed for any
   * {@linkplain RemovalCause reason}. Each cache created by this builder will invoke this listener
   * as part of the routine maintenance described in the class documentation above.
   *
   * <p><b>Warning:</b> after invoking this method, do not continue to use <i>this</i> cache builder
   * reference; instead use the reference this method <i>returns</i>. At runtime, these point to the
   * same instance, but only the returned reference has the correct generic type information so as
   * to ensure type safety. For best results, use the standard method-chaining idiom illustrated in
   * the class documentation above, configuring a builder and building your cache in a single
   * statement. Failure to heed this advice can result in a {@link ClassCastException} being thrown
   * by a cache operation at some <i>undefined</i> point in the future.
   *
   * <p><b>Warning:</b> any exception thrown by {@code listener} will <i>not</i> be propagated to
   * the {@code Cache} user, only logged via a {@link Logger}.
   *
   * @return the cache builder reference that should be used instead of {@code this} for any
   *     remaining configuration and cache building
   * @return this {@code CacheBuilder} instance (for chaining)
   * @throws IllegalStateException if a removal listener was already set
   */
  @CheckReturnValue
  public <K1 extends K, V1 extends V> CacheBuilder<K1, V1> removalListener(
      RemovalListener<? super K1, ? super V1> listener) {
    checkState(this.removalListener == null);
    
    @SuppressWarnings("unchecked")
    CacheBuilder<K1, V1> me = (CacheBuilder<K1, V1>) this;
    me.removalListener = checkNotNull(listener);
    return me;