What does it mean that ConcurrentLinkedHashMap has been integrated into Guava?

Question

We use ConcurrentLinkedHashMap from https://code.google.com/p/concurrentlinkedhashmap/ in a project and I saw a note that it was integrated into Guava's MapMaker and CacheBuilder back in 2010. The info is very brief:

Integration of the algorithmic techniques into MapMaker will be released in Google Guava r08 and is heavily based on this version.

What does it mean exactly?

• The concurrentlinkedhashmap project seems to be still active.
• Was it just a one time integration to bootstrap the Guava cache package?
• Have the two projects evolved independently since 2010?
• If so, what are the main differences between them today?

Answer 1

What does it mean exactly?

Guava is the long term replacement and most of the time you should use it. The history is that ConcurrentLinkedHashMap figured out the algorithms, Guava subsumed it, and then focused on adding features.

The concurrentlinkedhashmap project seems to be still active.

It has always been a weekend project, so active means that I have a scratch to itch or responded to a change request. It is also easier to experiment in CLHM than Guava, so I tended to prove out ideas there prior us porting them over. My involvement with Guava was as a 20%-er.

Was it just a one time integration to bootstrap the Guava cache package?

Yes. We first overhauled MapMaker and then split out caching into a dedicated API. It is a one-way migration of ideas and improvements into Guava.

Have the two projects evolved independently since 2010?

Both have stayed dedicated to their goals. The motivation behind ConcurrentLinkedHashMap was to figure out how to write a truly concurrent cache without taking shortcuts. The goal behind Guava is to provide a feature rich library with a beautiful API and solid implementation for broad usage.

What are the main differences between them today?

Guava is packed with features and has a full time team at Google supporting it. Use it!

ConcurrentLinkedHashMap has higher absolute concurrency by decorating, instead of forking, ConcurrentHashMap. This allows it to be used with ConcurrentHashMapV8, which is based on a new algorithm. CLHM does not relying on segment locks, which improves write performance and allows for maintaining a single LRU chain. I have an experimental branch with the LIRS policy that I hope to someday finish.

The long term hope is that Doug Lea will one day write a cache inspired by our work and teach us a few things in the process.

---

Update (3/15): Caffeine is a Java 8 rewrite of Guava's cache. It tries to provide the best of ConcurrentLinkedHashMap and Guava, modernized with Java 8, and adopting the techniques that I've learned since those previous projects.