I ended up writing my own HashMap implementation for the Scala standard library and was surprised at how easy it was to beat java.util.HashMap in performance.

The avoidance of dependencies makes sense. I figured that was probably the case, just thought I’d mention it as prior art rather than jump right in and tell you to write your own. :-)

Does anyone know why the @author(s) Bloch and Gafter did it this way? It seems so wrongheaded. The only motivation I see is to have a single implementation of hashing. Their approach also makes having null entries simpler, but come on, that could’ve been handled with a single boolean, though it’d sure complicate all the implementations.

Somewhere in the back of my mind, I knew that Java’s hash sets were implemented on top of their maps. If I’d profiled my new implementation versus the default one, it would’ve also become obvious.

We try to stay away from any dependencies other than Java. Paying customers seem to be allergic to GPL-like dependencies (though tolerant of Apache and often excepting MySQL and Linux from their GPL aversion).

I have written a bunch of other collection extensions, mainly for small sized collections to save space. Next up, a space efficient resizable hash set.

I’ve been meaning to write primitive-specific collections for a while, but I so rarely use Java collections for primitives in a tight loop that they’ve never been a bottleneck, so I’ve never gotten around to it.

In the meantime, you might be better off using gnu trove (it’s LGPL, so the license is tolerable) or implementing your own open addressing based HashSet (it’s not overly hard) if you don’t want the dependency.