When you sum a large IntStream the result can be wrong even though no exception is thrown. Why, and how does the design of primitive streams shape how you'd prevent it?

## Background: fixed-width integers wrap silently A Java `int` is a **32-bit two's-complement** integer: it can represent values from `-2,147,483,648` to `2,147,483,647` (`Integer.MIN_VALUE`..`Integer.MAX_VALUE`). Ordinary `+` arithmetic on `int`s does **not** check for overflow — when a result exceeds the range it **wraps around** (modular arithmetic). For example `Integer.MAX_VALUE + 1` becomes `Integer.MIN_VALUE` (a large negative number). No exception, no warning — just a wrong value. (`Math.addExact` *does* throw, but the `+` operator and stream `sum()` do not.) ## Why IntStream.sum() inherits this `IntStream.sum()` is defined to return an **`int`**. Internally it keeps a running `int` accumulator and adds each element. So summing a stream whose total exceeds ~2.1 billion (e.g. 3 million elements averaging 1000, or a few elements near `MAX_VALUE`) **overflows silently** and returns garbage — often negative. The pipeline runs without error; only the number is wrong. This is one of the most common subtle bugs in numeric stream code. ## How the design forces the responsibility onto you Primitive streams are **width-specialized**: `IntStream` is *about* `int`s, and its `sum()` returns an `int` by contract. The type system will **not** silently promote the accumulator to `long` for you — that would contradict the explicit, no-boxing, predictable-type philosophy of these streams. The flip side of getting an exact, unboxed numeric type is that **choosing a wide-enough accumulator is your job**. The design gives you the tools to widen explicitly; it does not guess. ## The fixes, in order of magnitude 1. **Widen to `long` (the usual fix).** Convert the stream so the accumulator is 64-bit before summing: - `intStream.asLongStream().sum()` — lossless widening of each `int` to `long`; `sum()` now returns a `long` (range ~9.2 quintillion). - or `objects.stream().mapToLong(o -> o.getCount()).sum()` — extract as `long` from the start. A `long` accumulator handles realistic totals of 32-bit element values. 2. **`long` can still overflow** if the data is extreme. For totals beyond 64 bits, map to **`BigInteger`** (arbitrary precision) and reduce: ```java BigInteger total = ints.stream() .mapToObj(BigInteger::valueOf) .reduce(BigInteger.ZERO, BigInteger::add); ``` This never overflows but is slower and re-introduces objects. 3. **Detect rather than tolerate.** If you'd rather fail loudly, reduce with `Math.addExact`, which throws `ArithmeticException` on overflow: ```java int total = ints.stream().reduce(0, Math::addExact); // throws if it would overflow ``` ## What about average() / other ops? - `average()` returns an `OptionalDouble` (a 64-bit floating-point mean), so it doesn't overflow the way integer `sum()` does — but `double` has only ~15-16 significant decimal digits, so with an enormous count or huge magnitudes you can lose **precision** (rounding), a different failure mode. - `count()` returns a `long`, so counting is safe to ~9.2 quintillion. - `summaryStatistics()`'s `getSum()` already returns a **`long`** for `IntStream`/`LongStream`, so using it is itself an overflow-safer way to get an int-stream sum. ## The takeaway The bug is real and silent: `IntStream.sum()` is an `int`. The width-specialized, no-boxing design that makes primitive streams fast also makes **accumulator width an explicit choice**. Default to `asLongStream().sum()` (or `mapToLong`) whenever the total could plausibly exceed two billion; escalate to `BigInteger` or `Math.addExact` when correctness must be guaranteed or loudly enforced.