building maps in java
rzwitserloot posted in programming on September 13th, 2006

Wherein I reveal a neat little tool to create list/set/map literals for java 1.5, inspired by Erling’s comment (4th comment) from my previous article.

---

I assert that arrays are pretty much ‘deprecated’ in java: the collections API (lists, sets, maps) are just more flexible in every way; there is very very little ground where it makes sense to use an array because they can do stuff better. Maybe for speed reasons for computer graphics programming and other such esoteric areas.

If you haven’t yet reached that conclusion, feel free to read my reasoning. It’s the first appendix attached to this story.

The unfortunate drawback to using the collections API is that it’s just a library - the language itself offers no fancy support for any of it. For example, PHP, javascript, ruby, and python all have a fairly simple way of making a map literal. The language syntax actually has a map literal primitive. example python code:

HTTP_CODES = {404: "Not Found", 403: "Forbidden", 200: "OK"}

However, in java, such a primitive does not exist. Furthermore, the library as it exists now never actually offered a decent way of making literals. The asList method offers a decent way of making lists on the fly, as in:

List myList = Arrays.asList(1, 2, 3, 4, 5);
List CONSTANTS = Collections.unmodifiableList(Arrays.asList(1, 2, 3, 4, 5));

But even that has problems; the returned list is array-backed, meaning that you can’t grow it. The add method throws an exception. Yet it cannot be used for constants verbatim, because setting new elements in the list is still legal, hence the need to wrap in an unmodifiableList call if thats the intent. Creating a list with a bunch of initial values which can still be grown requires this kind of tripe:

List numbers = new ArrayList();
numbers.addAll(Arrays.asList(1,2,3,4,5);

Ugh. two lines, can’t even be written as a simple attribute assignment anymore. ug-ly. Now try to make a map (or set) constant, and you’ll cry:

private static final Map HTTP_CODES;

static {
    Map codes = new HashMap();
    codes.put(404, “Not Found”);
    codes.put(403, “Forbidden”);
    codes.put(200, “OK”);
    HTTP_CODES = Collections.unmodifiableMap(codes);
}

Compared to the python example you gain type safety and immutability but that’s ridiculously (and needlessly) wordy!

Here’s the fix. First, the syntax for creating one:

private static final Map HTTP_CODES = Map.put(404, “Not Found”)
    .put(403, “Forbidden”).put(200, “OK”).immutable();

Woohoo! one liner again!
The above assumes that sun adds the static ‘put’ method to the Map inteface. Since java 1.6 it’s legal to put static methods in interfaces. However, until that happends, here’s an almost-as-good implementation. Replace ‘Map’ with ‘MapBuilder’ above and it all works:
code for MapBuilder.java:

package example;

import java.util.Collections;
import java.util.HashMap;
import java.util.LinkedHashMap;
import java.util.Map;
import java.util.TreeMap;

public class MapBuilder {
	private Map map;
	private boolean closed = false;

	private MapBuilder(Map map) {
		this.map = map;
	}

	public static  MapBuilder linked(K key, V value) {
		Map map = new LinkedHashMap();
		map.put(key, value);
		return new MapBuilder(map);
	}

	public static  MapBuilder plain(K key, V value) {
		Map map = new HashMap();
		map.put(key, value);
		return new MapBuilder(map);
	}

	public static  MapBuilder tree(K key, V value) {
		Map map = new TreeMap();
		map.put(key, value);
		return new MapBuilder(map);
	}

	public MapBuilder put(K key, V value) {
		if ( closed ) throw new IllegalStateException();
		map.put(key, value);
		return this;
	}

	public Map mutable() {
		closed = true;
		return map;
	}

	public Map immutable() {
		closed = true;
		return Collections.unmodifiableMap(map);
	}
}

---

Appendix 1
Why you should always use the collections API:
Since java 1.2, the so called ‘collections framework’ offers all the usual suspects in Data Structures: collections, lists, sets, and maps. Since java 1.5, you can use generics to enforce type safety and avoid unseemly casting. For example, to find the largest number amongst a set, you could try the following:

public static int max(List list) {
    int largest = Integer.MIN_INT;
    if ( list.size() == 0 ) throw new IllegalArgumentException();
    for ( int x : list ) if ( x > largest ) largest = x;
    return x;
}

Note how type safety is secured all around. The same thing but with arrays looks like:

public static int max(int[] list) {
   int largest = Integer.MIN_INT;
   if ( list.length == 0 ) throw new IllegalArgumentException();
   for ( int x : list ) if ( x > largest ) largest = x;
}

Those two code snippets are virtually equal to each other. However, unlike arrays, lists can grow, they are actually more flexible, type safety wise (because arrays do not play all that nicely with generics, and generics allow for some very nifty type safety devices.

Everything an array can do can be done just as easily with a genericsified list, whereas there are loads of things lists can do that got arrays stumped. Such as, oh, say, growing on demand, or printing nicely.