Sure about this likings!

Google Collections presentation PPT

The Google Collections Library (for Java) by Kevin Bourrillion, Google, Inc.
SV-GTUG 2008-08-06

Reference : Google Collections libraries and details

In a nutshell

  • An open-source (Apache 2) library


  • Requires JDK 1.5

  • Pre-release snapshot available, 0.9 release coming

  • Not API-frozen until release 1.0 (no timetable)

  • But is widely used in production at Google

  • Developers: Jared Levy and myself, with a lot of help from our friends

  • Overview

    1. In a nutshell
    2. Immutable Collections
    3. Multisets
    4. Multimaps
    5. Other new types/impls
    6. Static utilities
    7. Other stuff
    8. Q & A

    Immutable Collections

  • JDK has Collections.unmodifiableFoo() wrappers

  • Unmodifiable = you can't change it

  • Immutable = it can never change, no matter what
    (externally-visible state, that is)

  • Immutability is tasty!
    See Effective Java for some of the many reasons

  • We (Google) provide

  • ImmutableList

  • ImmutableSet

  • ImmutableSortedSet

  • ImmutableMap

  • ImmutableSortedMap (one day)

  • Brand-new, standalone implementations

    Immutable vs. unmodifiable

    The JDK wrappers are still useful for unmodifiable views of
    changing data. But for most purposes, use ours:

  • Immutability guarantee!

  • Very easy to use

  • (we'll show you on the following slides)

  • Slightly faster

  • Use less memory
    Sometimes far less (ImmutableSet, factor of 2-3x)

  • Constant sets: Before, v1

    public static final Set LUCKY_NUMBERS;
    static {
    Set set = new LinkedHashSet();
    LUCKY_NUMBERS = Collections.unmodifiableSet(set);

    Constant sets: Before, v2

    public static final Set LUCKY_NUMBERS
    = Collections.unmodifiableSet(
    new LinkedHashSet(
    Arrays.asList(4, 8, 15, 16, 23, 42)));

  • A little nicer.

  • But uses four different classes! Something's weird.

  • Constant sets: After

    public static final ImmutableSet LUCKY_NUMBERS = ImmutableSet.of(4, 8, 15, 16, 23, 42);

  • Now we just say exactly what we mean.

  • And get performance benefits as well!

  • We're using just one class (it implements Set)

  • of() method name inspired by java.util.EnumSet

  • Constant maps: Before

    public static final Map ENGLISH_TO_INT;
    static {
    Map map = new LinkedHashMap();
    map.put("four", 4);
    map.put("eight", 8);
    map.put("fifteen", 15);
    map.put("sixteen", 16);
    map.put("twenty-three", 23);
    map.put("forty-two", 42);
    ENGLISH_TO_INT = Collections.unmodifiableMap(map);

    Constant maps: After

    public static final ImmutableMap
    ENGLISH_TO_INT = ImmutableMap
    .with("four", 4)
    .with("eight", 8)
    .with("fifteen", 15)
    .with("sixteen", 16)
    .with("twenty-three", 23)
    .with("forty-two", 42)

    Defensive copies: Before

    private final Set luckyNumbers;
    public Dharma(Set numbers) {
    luckyNumbers = Collections.unmodifiableSet(
    new LinkedHashSet(numbers));
    public Set getLuckyNumbers() {
    return luckyNumbers;

  • Copy on the way in

  • Wrap in unmodifiable on the way in or the way out

  • Defensive copies: After

    private final ImmutableSet luckyNumbers;
    public Dharma(Set numbers) {
    luckyNumbers = ImmutableSet.copyOf(numbers);
    public ImmutableSet getLuckyNumbers() {
    return luckyNumbers;

  • Type, not just implementation

  • What if you forget?

  • Note: copyOf() cheats!

  • Immutable Collections: more examples

    static final ImmutableSet BETA_COUNTRIES = ...
    ImmutableSet.of(a, b, c);

    Small maps:
    static final ImmutableMap MAP
    = ImmutableMap.of(1, "one", 2, "two");

    Immutable Collections: caveats

    These collections are null-hostile
    In 95%+ of cases, this is what you want
    In other cases, fine workarounds exist
    This aligns with recent work on JDK collections
    (and it's a little faster this way)
    (and keeps the implementation simpler)
    Mutable elements can sometimes lead to confusion
    The resulting object won't be "deeply immutable"

    Immutable Collections: summary

  • In the past, we'd ask, "does this need to be immutable?"
  • Now we ask, "does it need to be mutable?"

  • Overview

    1. In a nutshell
    2. Immutable Collections
    3. Multisets
    4. Multimaps
    5. Other new types/impls
    6. Static utilities
    7. Other stuff
    8. Q & A

    Collection behavior

    When you have "a bunch of foos", use a Collection -- but what

  • Can it have duplicates?
  • Is ordering significant? (for equals())
  • Iteration order
  • - insertion-ordered? comparator-ordered? user-ordered?
    - something else well-defined?
    - or it just doesn't matter?

    In general, the first two determine the interface type, and the
    third tends to influence your choice of implementation.

    No comments:

    Add to My Yahoo!                       
    Custom Search