Okay, that makes sense, although in some ways it seems more like a rationale for keeping _an_ interface, rather than a rationale that Jena should have its _own_ interface. But keeping Guava types from leaking through makes sense.
I will send a PR sometime soon with some Java 8 work in those Cache implementations (e.g. taking advantage of the new Map.computeIfAbsent() method to shorten and tighten some code and maybe using default method implementations to be a bit DRYer), but I won't alter Jena's Cache type itself. Then everyone can decide whether those are legitimate improvements in implementation without effect on API. --- A. Soroka The University of Virginia Library On May 7, 2015, at 5:53 AM, Andy Seaborne <[email protected]> wrote: > On 06/05/15 22:30, A. Soroka wrote: >> I've found another candidate for simplification (well, actually for >> excision): >> >> org.apache.jena.atlas.lib.cache contains several classes that >> implement an interface org.apache.jena.atlas.lib.Cache. This >> interface very closely resembles Guava's >> com.google.common.cache.Cache, and I believe that the Guava type >> could be substituted without too much fuss. The entire package >> org.apache.jena.atlas.lib.cache could go away, along with the >> >> Does this seem like a worthwhile replacement? >> >> --- A. Soroka The University of Virginia Library >> > > We do now use Guava cache (shaded) with the CacheGuava implementation of > Cache. The naming of getIfPresent or getOrFill was put in recently to > reflect the Guava design (and the safe atomic getOrFill is quite useful > sometimes - not always - TDB has "bi-caches" that need synhronized chnages). > > Having our own Cache interface means different providers can be used. We may > find a better one for certain circumstances. The interface stops guava-isms > like RemovalNotification leaking out too far. > > So on balance, I'm more inclined to keep it because we have the current > interface already. > > Andy
