Make `Striped.custom` public

[Mattias Hellborg Arthursson]

API(s)

`com.google.common.util.concurrent.Striped::custom`

How do you want it to be improved?

Making this function public rather than package protected would open up the Striped class to be used with different types of locks.

Why do we need it to be improved?

I want to use Striped to manage Mutex instances for use with Kotlin coroutines.

Example

(In Kotlin):

package com.example.concurrent
val stripedMutex = Striped.custom(size) { Mutex() }

Current Behavior

The above can currently only be implemented if the calling code resides in the com.google.common.util.concurrent package, which is doable but ugly.

Desired Behavior

I would like to be able to make the call above without having to place the code in the com.google.common.util.concurrent package, e.g.:

package com.example.concurrent

fun StripedMutex(size: Int): Striped<Mutex> =
    Striped.custom(size) { Mutex() }

suspend fun <T> Striped<Mutex>.withLockFor(key: Any, block: suspend () -> T) : T =
    get(key).withLock { block() }

Concrete Use Cases

The recommended synchronization mechanism for Kotin coroutines is using kotlinx.coroutines.sync.Mutex or kotlinx.coroutines.sync.Semaphore instances. It would be nice if the Striped would be usable for these cases as well. To be honest, I'm struggling to understand the reasoning behind making the custom function package protected in the first place.

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.

[Chris Povirk]

I feel bad about this (#2514). It's one of those changes that's significant enough to require our relatively heavyweight review process but not widely used enough to clearly justify the effort :( Hopefully someday, but it's probably going to have to wait until we make a proper push on long-standing feature requests.

[Mattias Hellborg Arthursson]

It seems to me - perhaps naively - that making a package private, static method public would be change small enough to fly under the radar pretty smoothly. Then again I'm the first to admit that I lack knowledge about your review process so I'm not going to make an argument :).

It is a shame however: this is a very useful class and making it open for extension would make it even more useful (I've encountered the need for this in two completely separate real-world projects).