FAQ

Why not just use java.util.* collections?

The Java Collections Framework is in many ways excellent (especially in conjunction with the streaming API in Java 1.8), but it cannot be directly used for primitive types without autoboxing. While for many smaller ad-hoc collections the overhead is minimal, when dealing with larger collections this becomes a problem. At Carrot Search we needed collections that were fast, memory-conservative and provided open access to internals (which is sometimes useful).

Why not another primitive collections library?

There are now a few projects implementing collections over primitive types: fastutil, GS collections, Koloboke, PCJ, GNU Trove, you name it. When we needed HPPC this was not the case. Fastutil was LGPL-ed, which many commercial companies tend to dislike, other libraries like pCJ were no longer maintained or complete.

We also admit that we simply liked toying with code. The idea that HPPC template classes can be written as valid Java classes and then translated into primitive variants seemed (and still seems) compelling.

When to use HPPC?

• You write high-performance low-level routines and need a small, focused primitive collections library.
• You need to access collections' internal data storage for application-specific optimizations.
• You do have some rudimentary understanding of the potential pitfalls of open addressing and linear hash collision resolution. HPPC provides two distinct types of associative containers to deal with this: scatter and hash sets (and maps).

When * not * to use HPPC?

• Your software uses data collections in non-critical code sections, with low-volumes of data. If so, stick with JCF, performance gain of nanoseconds is not worth the overhead.
• You need the flexibility of Java Collections and are prepared to sacrifice runtime performance for easier coding. In that case, stick with JCF, perhaps enhanced with Guava.
• You're not confident enough that your unit- and regression tests will catch invalid parameters or states; you would like to have the validation done also in production.
• You cannot bear with occasional compatibility-breaking API refactoring; HPPC is a toy project (although stable and used in production software).
• You write mission-critical software and would feel uneasy about including HPPC in it.