HPPC:

Motivation

The ultimate goal of HPPC is to address computationally-intensive scenarios as a priority. Encapsulation, fail-fast behaviour, thread-safety and beauty of the API are of secondary importance.

Assumptions and design decisions behind HPPC
Assumption Design implications
Programmers know what they're doing. In order to write highest-performing code, they may wish to access the internal storage of a collection directly rather than use the built-in iterators. Simple data types, internal storage exposed for application-specific optimisations. HPPC provides utilities for the most common tasks like filtering, iterating or joining collections, but these are usually more expensive than direct access to the low-level data storage.
No interfaces and class hierarchies. The programmer chooses the best collection implementation at design-time based on the desired characteristics.
No support for Java serialization. There are many other libraries that handle serialization.
Single-threaded access prevails. Vast majority of low-level computation code is single-threaded and therefore there is little point in verification of concurrent modifications and synchronization. Not thread-safe implementations, concurrent modification attempts are not detected.
Solid unit- and regression-testing. The programs that use primitive collections are heavily unit- and regression-tested during development, so their behavior in production systems does not have to be restrictively verified. Optional verification. Verification of parameter and state validity is done optionally using assertions. This means that contracts are only checked if requested at runtime (using Java 1.4+ -ea switch). Production-ready code can run with no additional overhead from contract checks.