Fyi, Looking at your backport, I suspect that you compiled with JDK6 in JDK5 mode. Unfortunately this does not exclude library changes, so I suggest using JDK5 instead. The Cayenne backport includes java.util.Deque in my LinkedDeque implementation, but this interface was not available in JDK5. It also is missing an override to AbstractCollection#toArray() to be safe from concurrent modifications causing an ArrayIndexOutOfBoundsException, which was fixed in JDK6.
Feel free to borrow from my JDK5 backport for the v1.2 release if it helps. [1] - Ben [1] http://code.google.com/p/concurrentlinkedhashmap/source/browse/#svn%2Ftags%2Fconcurrentlinkedhashmap-lru-1.2_jdk5%2Fsrc%2Fjava%2Fcom%2Fgooglecode%2Fconcurrentlinkedhashmap On Thu, Feb 23, 2012 at 10:54 PM, Andrus Adamchik <[email protected]>wrote: > Hi Ben, > > Thanks for dropping a note :) It is very good to know that CLHM is a > supported and evolving technology. > > There's no dependency on Guava, so it felt like internalizing > ConcurrentLinkedHashMap was the right thing at the moment. This is not a > final decision, especially since we'll be working on unifying the 2 caches > (object cache and query result cache) at some point. But for now it felt > like the easiest way to get things going without exposing the internals to > the end users. > > With your message contributing to my confidence in CLHM, the most > important remaining question for us right now is whether the removal of > synchronizations spanning multiple get/put operations will cause any > undesired effects. But this is purely a Cayenne thing, untreated to the > underlying cache, so we'll have to deal with that on our own. > > Thanks! > Andrus > > > On Feb 24, 2012, at 12:05 AM, Benjamin Manes wrote: > > Hi, > > I'm the author of CLHM, brought to you by a friendly Google alert. :) > > > > If Cayenne is currently using Guava, then there won't be a dependency > increase. I helped rearchitect MapMaker and design its replacement, > CacheBuilder, which are based on CLHM's algorithms. This is a more > feature-rich implementation with the support of a team at Google (whereas > CLHM is my weekend project). We also fixed my mistake of only weighing by > value, since I hadn't realized how popular memory-based weighing would be > (I was trying to avoid unbounded collections as values). > > > > Technically CLHM provides more concurrency than CacheBuilder by not > relying on segment locks and later using a lock-free ring buffer. These > will be an advantage when it is backed by JDK8's new CHM (see > ConcurrentHashMapV8) or Cliff Click's NBHM. A JSR-166 implementation will > be a marriage of CHMv8, CLHM, and CacheBuilder. > > > > CLHM is back-ported to JDK5 on every release, so you'll find the JDK5 > source under /tags. I do development on /trunk assuming JDK6. > > > > Feel free to file issues against CLHM (or Guava) if you'd like > enhancements to either. Both are used in large production environments. > > > > Cheers, > > Ben > >
