groovy-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From paulk-asert <...@git.apache.org>
Subject [GitHub] groovy pull request #679: GROOVY-8525: Binary compatibility issue for Groovy...
Date Sat, 31 Mar 2018 03:37:32 GMT
Github user paulk-asert commented on a diff in the pull request:

    https://github.com/apache/groovy/pull/679#discussion_r178422137
  
    --- Diff: src/main/java/org/codehaus/groovy/runtime/memoize/StampedCommonCache.java ---
    @@ -175,6 +174,11 @@ private V compute(K key, ValueProvider<? super K, ? extends V>
valueProvider, bo
             return doWithReadLock(c -> c.values());
         }
     
    +    @Override
    +    public Set<Entry<K, V>> entrySet() {
    +        return commonCache.entrySet();
    --- End diff --
    
    Inelegant but the Java collections way! ;-) Better to look inelegant rather than provide
an apparently good looking but buggy implementation! In any case, I have implemented entrySet()
in the same way as keys() and values() are implemented. The concern though is that if you
look at ConcurrentHashMap, keySet(), entrySet() and values() are backed by views using iterators
and spliterators that guarantee "weak consistency". It doesn't seem like we are making any
such considerations for StampedCommonCache? I will leave that as a future exercise - we can
always create such views or throw UnsupportedOperationException if we deem there is no other
way to be safe.


---

Mime
View raw message