Add Duration support for CacheBuilder.expireAfterWrite like in other guava projects

[glyiu98]

1. What are you trying to do?

I noticed that Guava has different projects which have their own implementation of CacheBuilder.
Some of them support an expireAfterWrite Duration while others not (like guava android)

Is this change planned?

Thanks!

2. What's the best code you can write to accomplish that without the new feature?

I would have to make some change son my code to not use the "bad" CacheBuilder.

3. What would that same code look like if we added your feature?

I would not have to do anything and guava CacheBuilder classes would be compatible.

(Optional) What would the method signatures for your feature look like?

No response

Concrete Use Cases

I have a project which which as a dependency A which on its turn as a dependency on com.google.guava:guava:jar:31.1 (CacheBuilder which supports Duration on expireAfterWrite).

I also have another dependency B which on its turn as a dependency on com.google.guava:guava:jar:32.0.1-android (CacheBuilder which doesn't support Duration on expireAfterWrite).

After compile, the dependency A is using the guava dependency B, which creates a conflict on the CacheBuilder expireAfterWrite.

Packages

No response

Checklist

• I agree to follow the code of conduct.

• I have read and understood the contribution guidelines.

• I have read and understood Guava's philosophy, and I strongly believe that this proposal aligns with it.

• I have visited the idea graveyard, and did not see anything similar to this idea.

[cpovirk]

Yes, we're aiming to add the Duration overloads to guava-android soon. The main thread for tracking additions of Java 8+ APIs is #6567, but I will try to remember to update this one when we add the Duration ones specifically.

Even once we do that, I'd still advise setting up your project to use a JRE version of Guava. Use a version whose number is at least as high as the highest version of Guava you depend on. In your case, that would mean 32.0.1-jre or higher. (I'd suggest going straight to the newest version, 33.2.0-jre, if you can.) This will ensure that all the Guava APIs are available to you even if we still don't add all of them to guava-android. It will also give you implementations that are better optimized for the JRE.

(We have some advice about this kind of JRE-Android conflict for users of Truth, another of our libraries. I should probably put something about it on the Guava site if we haven't already....)

[glyiu98]

Hey @cpovirk, thank you for the prompt reply! Indeed I would do that but one of my dependencies is gRPC which is using the guava-android, so I cannot do anything for now. I will just go with another workaround for now.

[cpovirk]

Ah, sorry, I didn't actually give advice on how to accomplish that :) If you declare a dependency in your own project on guava-33.2.0-jre, then that should take precedence over the other deps, since Maven picks the highest version number. guava-33.2.0-jre contains all the APIs of 31.1-jre and all the APIs of 32.0.1-android[*], so you should be safe.

[*] OK, OK: Guava 33 did remove some APIs from guava-android that didn't work anyway—hence the bump in the major version number. Guava 32 didn't even do that, but it did remove an API in a separate artifact. Those removals will not be a problem in practice.

[glyiu98]

Okok thanks for the help, will do that :)