Thanks for the feedback Phil!
> One way to do this would be to have the current property be a cap on > the total number of tests performed, but the new one basically > control the number done per key. So if, e.g. numTestsPerEvictionRun > is 12, numEvictionTestsPerKey (or whatever we decide to call it) is > 3, the evictor does 3 tests for each key and then moves on to the > next immediately, up to 12. I guess if there are fewer than > numEvictionTestsPerKey, the evictor just moves on. If the evictor > gets all the way through before numTestsPerEcvictionRun it could > wrap around or just stop. Would something like that work for you? > Anyone have any better ideas? "No more than numEvictionTestsPerKey per key and no more than numTestsPerEvictionRun total" would definitely address my use case (in my case, I'll just set numTestsPerEvictionRun to Int.MAX or something), but I do wonder if that's what everyone would want. I could imagine expecting the behavior to be "At least numEvictionTestsPerKey per key and at least numTestsPerEvictionRun total" (which would be the behavior if we wrapped around instead of just stopping). I suppose it's easy to make it clear which behavior we have in documentation, but that presumes the one I want is likely to be universally more useful than the alternative. Think I can make that assumption? With respect to naming: numEvictionTestsPerKey is definitely more concise and readable than numTestsPerEvictionRunPerKey, but I wonder if it makes it less obvious that it's tightly connected to numTestsPerEvictionRun. In code completion, the setters wouldn't appear next to each other, which might hurt discoverability. Maybe just referencing each other in docs is enough to mitigate that. Any votes one way or the other?
