Use Iterator.remove when trimming cache

[unverbraucht]

Description

Instead of explicitly removing a key from the LruCache (which fails if the key class violates the equals() contract) call remove() on the iterator instead.

Motivation and Context

Using this even cache keys violating equals() can be used here. Fixes #2532.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If your company signed a CLA, they designated a Point of Contact who decides which employees are authorized to participate. You may need to contact the Point of Contact for your company and ask to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the project maintainer to go/cla#troubleshoot.
• In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again.

[unverbraucht]

I signed it!

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for the commit author(s). If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again.

[unverbraucht]

I'm unable to change the email on the CLA, it is always set to my gmail addresseven after changing my Google settings to use my new one. Maybe somebody else can re-apply the patch?

[googlebot]

CLAs look good, thanks!

[TWiStErRob]

is there a chance of ConcurrentModificationException because of this line?

[unverbraucht]

No, using the Iterator to remove is safe when using the Iterator itself to loop over the collection. I added another commit to ensure that we don't overrun the collection, although I don't see how it could happen unless the size to trim to is <0. Can't hurt though I guess.

[TWiStErRob]

@sjudd before you merge, please consider this test (it throws with new code):

  @Test
  public void testPreventEviction() {
    final MemoryCache cache = new LruResourceCache(100);
    final Resource<?> first = getResource(30);
    final Key firstKey = new MockKey();
    cache.put(firstKey, first);
    Resource<?> second = getResource(30);
    Key secondKey = new MockKey();
    cache.put(secondKey, second);
    Resource<?> third = getResource(30);
    Key thirdKey = new MockKey();
    cache.put(thirdKey, third);
    cache.setResourceRemovedListener(new ResourceRemovedListener() {
      @Override
      public void onResourceRemoved(Resource<?> removed) {
        if (removed == first) {
          cache.put(firstKey, first);
        }
      }
    });

    // trims from 100 to 50, having 30+30+30 items, it should trim to 1 item
    cache.trimMemory(ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN);

    // and that 1 item must be first, because it's forced to return to cache in the listener
    @SuppressWarnings("unchecked")
    LruCache<Key, Resource<?>> lruCache = (LruCache<Key, Resource<?>>) cache;
    assertTrue(lruCache.contains(firstKey));
    assertFalse(lruCache.contains(secondKey));
    assertFalse(lruCache.contains(thirdKey));
  }

[sjudd]

@unverbraucht thoughts? I don't think we typically have concurrent modifications like this, but it's probably possible (and may be why the code was written the way it was initially).

[unverbraucht]

@sjudd @TWiStErRob good point. It might make sense then to get a fresh instance of the Iterator after every loop run. I've committed proposed changes for that.

[sjudd]

LGTM, just waiting on 4.3.1 to go out before merging.

[TWiStErRob]

just a preference (declare close to usage, and in scope): these two vars are only used within the loop, so they could be defined inside:

final Iterator<Map.Entry<T, Y>> cacheIterator  = cache.entrySet().iterator();
final Map.Entry<T, Y> last = cacheIterator.next();

[sjudd]

I agree in principle, but this matches the existing style, so let's just leave it as is for now.

[sjudd]

Thanks!