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

http://google-collections.googlecode.com

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();
set.add(4);
set.add(8);
set.add(15);
set.add(16);
set.add(23);
set.add(42);
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)
.build();


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

Sets:
static final ImmutableSet BETA_COUNTRIES = ...
ImmutableSet.of();
ImmutableSet.of(a);
ImmutableSet.of(a, b, c);
ImmutableSet.copyOf(someIterator);
ImmutableSet.copyOf(someIterable);

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
kind?

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.