Add java.time.Duration overloads to Suppliers.memoizeWithExpiration()

[cowwoc]

Suppliers.memoizeWithExpiration() takes a TimeUnit. Consider adding a java.time.Duration overload similar to what you did with CacheBuilder.

[kluever]

Funny you bring that up...I just had a need for that last week and have an internal CL out that adds the java.time.Duration overload. However, the CL has been stalled because we're trying to determine what to do for the parameter and return types re. legacy, soft-deprecated com.google.common.base.Supplier vs. Java's java.util.function.Supplier.

Should we accept the j.u.f.Supplier but return the c.g.c.b.Supplier? (i.e., "liberal in what you accept, conservative in what you return" - Robustness Principle)?

Should we accept and return j.u.f.Supplier?

Other ideas?

[cowwoc]

@kluever
My 2 cents: all Guava APIs that expect a c.g.c.b.Supplier argument should allow j.u.f.Supplier as well. Where they don't already do so, overloads should be added. I would even go so far as formally deprecating c.g.c.b.Supplier explicitly.

Once this is done, I see no benefit in returning com.google.common.base.Supplier.

[kluever]

All APIs that accept a c.g.c.b.Supplier already can accept a j.u.f.Supplier, because c.g.c.b.Supplier extends j.u.f.Supplier.

For this particular case:
The argument for accepting j.u.f is that now folks can pass either j.u.f or c.g.c.b to the method. Of course both of these would work if we accepted c.g.c.b instead.
The argument for returning c.g.c.b is that folks can assign the return type to either a variable of type j.u.f or c.g.c.b.

[cowwoc]

@kluever I would suggest hard-deprecating c.g.c.b.Supplier to simplify these kind of decisions. That being said, here is my reasoning:

• Users want to use a new Java 8 API: Duration
• This means their codebase has access to j.u.f.Supplier
• If we use j.u.f.Supplier exclusively, we're telling them if you want to use this Java8-specific API then you also need to update your code to use this other Java8-specific API.

After all, users don't need to "upgrade" to using Duration in the first place. If they're already making the migration from TimeUnit this is just a related upgrade for them to make.

[kluever]

I tend to agree with you. It is a little weird that we're mixing APIs that accept/return c.g.c.b.Supplier and j.u.f.Supplier in a class called c.g.c.b.Suppliers, but I'm not sure where else they would go.

[nikhilbarar]

Can i pick this up?

Will this work:

public static <T> c.g.c.b.Supplier<T> memoizeWithExpiration(
      c.g.c.b.Supplier<T> delegate, j.t.Duration duration)

[kluever]

@nikhilbarar thanks for the offer, but I actually have a pending change out for this - we just need to work through the Guava Supplier vs. JDK Supplier issue.