Google Collections 1.0 Offers Enhanced Implementations of the Java Collections Framework

Posted by Josh Long on Jan 15, 2010

Sections

Architecture & Design,

Development,

Operations & Infrastructure

Topics

Data Access ,

Java

Tags

Java SE ,

Google

The Google Collections Library, version 1.0-final, was released on December 30, 2009. You may download it at http://code.google.com/p/google-collections/. The library is the brainchild of Google engineers Kevin Bourrillion and Jared Levy. It has seen substantial growth in recent years thanks to the contributions of other Google engineers (like Doug Lea, Josh Bloch and Bob Lee), and the open source community at large.

The library aims at extending the Java platform's built-in collections library. The JDK collections library – as it stands today – lives in the java.util.* package. It is rooted primarily by a handful of interfaces: java.util.Collection (the super interface), java.util.Set, java.util.SortedSet, java.util.Map, and java.util.List. These interfaces dictate the contract behind the various implementations that ship with the JDK. java.util.Set loosely defines a collection of unordered, unique elements; java.util.SortedSet describes a collection of ordered, unique elements; java.util.Map defines an association – often termed a dictionary in other languages – of keys and values, and java.util.List defines an ordered collection of elements whose cardinality is variable. The original framework, designed by Josh Bloch when he worked at Sun, revolves around three ideas: interfaces, implementations (both concrete and abstract) and algorithms that allow you to manipulate the collections in an extensible way. These interfaces were introduced as a substantial overhaul of the classes provided by the earlier JDKs (java.util.Vector, java.util.Hashset, etc). Josh Bloch indicated in this 2008 Google Techcast that the Google Collections Library was developed in a way that he was comfortable with.

The Google Collections Library also offers new utility implementations and a focused set of libraries concerned with concurrency, including immutable collection implementations. “Immutability” guarantees that no other actor in the system – even the implementation itself – will change the state of the collection, while “unmodifiable” (as guaranteed by the JDK’s java.util.Collections class’ unmodifiable* factory methods) only guarantees that the client of the collection – the user – can never change the collection. Often, the implementations are not JDK wrappers, but finely tuned, memory sensitive, re-implementations of the interfaces. The Google Collections Library provides numerous static factory methods and builders (often both) by which objects may be created. Sometimes these are simply utility methods to subvert redundant type declaration:

import com.google.common.collect.*;
...
HashSet<String> hashSet = Sets.newHashSet();
LinkedHashSet<String> linkedHashSet = Sets.newLinkedHashSet();
ArrayList<String> arrayList = Lists.newArrayList();
LinkedList<String> linkedList = Lists.newLinkedList();

Other times, the static factory methods or builders are used because the implementations have no public constructors. The creation of subclasses is undesirable in many cases because the immutability contract might be compromised by a subclass. The Immutable* interfaces in the Google Collections Library signal to the client of the collections that a collection carries a guarantee of immutability, as well as implements the semantics of their JDK base interfaces’ contract. Users of the collections should pass around references to the Immutable* interface where possible.

import com.google.common.collect.*;
...
ImmutableSet<Integer> immutableSet = ImmutableSet.of(1, 2, 3, 4, 5);
ImmutableList<String> immutableList = ImmutableList.of("a,b,c,d,e,f,g".split(","));

The library offers some unique library implementations, too, including the MultiMap and MultiSet collections which describe collections of objects whose cardinality or frequency in the collection you can interrogate. Thus, to store multiple values associated with one key, you might use the following:

Multimap<String, Integer> personAndFavoriteNumbers = ArrayListMultimap.create();
personAndFavoriteNumbers.put("josh", 42);
personAndFavoriteNumbers.put("josh", 7);
Collection<Integer>numbers = personAndFavoriteNumbers.get("josh"); // doesn't return Integer
System.out.println(numbers .size()) ; // == 2

Note that get(String) returns a view associated with a key. If there are no values in the map for a given key, an empty collection will be returned. If you add items to the view collection, they are reflected in the Multimap:

Collection<Integer>numbers = personAndFavoriteNumbers.get("josh");
System.out.println(numbers .size()) ; // == 2
numbers.add( 0) ;
System.out.println(numbers .size()) ; // == 3
System.out.println(personAndFavoriteNumbers.get("josh").size() ) ; // == 3

There are also numerous concurrent implementations available for all the custom interfaces:

ConcurrentHashMultiset<String> concurrentHashMultiset =
ConcurrentHashMultiset.create(Arrays.asList("a,b,c,d,e,f".split(",")));

The Google Collections Library offers niceties for working with various functional programming idioms using the com.google.common.base.Predicate class:

import com.google.common.collect.*;
…
Iterable<Integer> filteredSet = Iterables.filter( someIterable, new Predicate<Integer>(){
public boolean apply( Integer integer) {
return integer > 0 ;
}
}) ;

Speaking to the library’s suitability, the library has a track record of production deployment at Google, and an exhaustive unit test suite of more than 25,000 tests. While the Google Collections Library is very promising, there are alternatives. Every iteration of the JDK benefits from new collections improvements. The Apache commons collections project also has some interesting collections implementations that predate this library by many years, though you will find that they are not as generics friendly. Looking forward, Kevin Bourrillion has said that the intention of the project was to formalize this library and then submit it to the JCP.

1. Back to top

   Blog post about Google Collections

   by Sune Simonsen

   Google Collections is a fantastic library that will only improve your code.
   
   If you are interested in learning more about the capabilities of Google Collections, I blogged about it here: blog.jayway.com/2009/10/22/google-collections/
   
   Sune Simonsen - Jayway

   Reply

2. Back to top

   Licensing issues

   by Boaz Lev

   Please notice that this package is under Apache 2 license, which is an LGPL family. This means that your dependent code is NOT open-sourceed, but in case you decide to sue Google for any reason - your license to use Google collections will be immediately revoked.

   Reply

3. Back to top

   Re: Licensing issues

   by Stuart McCulloch

   Please notice that this package is under Apache 2 license, which is an LGPL family. This means that your dependent code is NOT open-sourceed, but in case you decide to sue Google for any reason - your license to use Google collections will be immediately revoked.

   IANAL, but that isn't quite right - the exact wording of the relevant part of the Apache License, Version 2.0 goes:

   If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

   Notice that it's the patent license that is revoked, not the copyright license. Maybe a small point, but I think it's an important one and seems reasonable to me.
   
   PS. all projects hosted on Google-Code should have a link to their code license (which may or may not be the Apache License) on the right-hand side of the main project page.

   Reply

4. Back to top

   Broken Link to Techcast/Tech Talk

   by Matt Passell

   It looks like something strange happened to the link to the video on YouTube. Here it is in unbroken form:
   www.youtube.com/watch?v=9ni_KEkHfto&annotat...
   
   --Matt

   Reply

5. Back to top

   Re: Broken Link to Techcast/Tech Talk

   by Ryan Slobojan

   Hi Matt,
   
   There was an error in the link - it's now been fixed. Thanks for the note!
   
   Ryan Slobojan
   Chief Editor, InfoQ.com

   Reply

6. Back to top

   Great to see as a inherent part of Java 7.

   by Christopher Churchill

   Wow! This is a fantastic implementation of the Collections API. It will be great if this could make it into the Java 7 SE, so that it comes with the JRE instead of adding this as a separate JAR.
   
   commons.collection.* instead of commons.collect.* would be nice with the IDEs doing a lot of autocompletion these days.

   Reply

7. Back to top

   Manipulating collection in a DSL style

   by Mario Fusco

   I totally agree: google collection is a great library. Moreover I also think that it is important at the same level not only how the collections are implemented but even to offer a way to manipulate them in a more effective way. The use of a library like lambdaj can simplify to reach this target by allowing to aggregate, sort, filter and group the objects in a collection in an easy to read DSL-style.

   Reply

• Older >