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.
* Cache#cleanUp}; such entries may be counted in {@link Cache#size}, but will never be visible to
 * read or write operations.
 *
 * <p>Certain cache configurations will result in the accrual of periodic maintenance tasks which
 * will be performed during write operations, or during occasional read operations in the absence of
 * writes. The {@link Cache#cleanUp} method of the returned cache will also perform maintenance, but
 * calling it should not be necessary with a high throughput cache. Only caches built with
 * {@linkplain #removalListener removalListener}, {@linkplain #expireAfterWrite expireAfterWrite},
 * {@linkplain #expireAfterAccess expireAfterAccess}, {@linkplain #weakKeys weakKeys}, {@linkplain
 * #weakValues weakValues}, or {@linkplain #softValues softValues} perform periodic maintenance.
 *
 * <p>The caches produced by {@code CacheBuilder} are serializable, and the deserialized caches
 * retain all the configuration properties of the original cache. Note that the serialized form does
 * <i>not</i> include cache contents, but only configuration.
 *
 * <p>See the Guava User Guide article on <a
 * href="https://github.com/google/guava/wiki/CachesExplained">caching</a> for a higher-level
 * explanation.
 *
 * @param <K> the most general key type this builder will be able to create caches for. This is
 *     normally {@code Object} unless it is constrained by using a method like {@code
 *     #removalListener}
 * @param <V> the most general value type this builder will be able to create caches for. This is
 *     normally {@code Object} unless it is constrained by using a method like {@code
 *     #removalListener}
 * @author Charles Fry
 * @author Kevin Bourrillion
 * @since 10.0
 */
@GwtCompatible(emulated = true)