What happens when an int computation exceeds Integer.MAX_VALUE in Java, and why?
answer
- Silent wrap, no exception
- Two's-complement clock: MAX+1 = MIN
- Arithmetic is modulo 2^N
- int = 32 bits, ±~2.1 billion
- Math.addExact to detect
basics
~10 sJava does not throw an error. The value silently wraps around: adding 1 to the largest int gives the smallest (most negative) int. No warning, no exception.
solid answer
~40 sJava integer arithmetic (byte, short, int, long, char) is performed modulo 2^N and silently wraps on overflow instead of throwing. An int is 32 bits, so Integer.MAX_VALUE is 2,147,483,647; adding 1 wraps to Integer.MIN_VALUE (-2,147,483,648). This is because Java uses two's-complement representation, where the bit pattern after the maximum positive value is the most negative value. The JLS mandates this behavior, so it is deterministic and portable, never undefined. The danger is that bugs are silent: a counter, an accumulator, or a size computation can produce a nonsensical negative result with no signal. To detect overflow you must check ranges yourself or use Math.addExact/multiplyExact, which throw ArithmeticException. Overflow is a classic source of security bugs (e.g. allocation sizes).
code
java · 9 linesint max = Integer.MAX_VALUE; // 2_147_483_647
System.out.println(max + 1); // -2147483648 (wraps, no error)
// Detect instead of wrap:
try {
Math.addExact(max, 1);
} catch (ArithmeticException e) {
System.out.println("overflow detected"); // this branch runs
}go deeper
Knows overflow does not throw — the value silently wraps to a (usually negative) number.
Explains two's-complement wraparound, modulo 2^N, the exact MAX+1 = MIN result, and names Math.addExact.
Connects it to real bugs (binary-search midpoint, allocation sizing), promotion-to-int for smaller types, and chooses long/BigInteger or *Exact deliberately.
Frames overflow as a class of silent correctness/security defects; sets team conventions (checked arithmetic at trust boundaries, static analysis, fuzzing) and reasons about cost trade-offs.
## What "overflow" means A computer stores an integer in a fixed number of bits. Java's `int` uses **32 bits**, so it can represent exactly 2^32 = 4,294,967,296 distinct values. Java's integer types are **signed**, so that range is split roughly in half between negatives and non-negatives: an `int` runs from **Integer.MIN_VALUE = -2,147,483,648** to **Integer.MAX_VALUE = 2,147,483,647**. **Overflow** is when an arithmetic result is too large to fit in that range; **underflow** (for integers) is the symmetric case of going below the minimum. ## Two's-complement: why it wraps the way it does Java represents signed integers in **two's-complement**. Think of the bit patterns as a circle (a "clock"). Counting up, you go ...MAX_VALUE, then the very next bit pattern is MIN_VALUE, then up toward -1, then 0, and around again. Concretely, the maximum positive int is `0x7FFFFFFF` (binary: a 0 sign bit followed by 31 ones). Add 1 and it becomes `0x80000000` (a 1 sign bit followed by 31 zeros) — which two's-complement reads as the **most negative** value, Integer.MIN_VALUE. So: ``` Integer.MAX_VALUE + 1 == Integer.MIN_VALUE Integer.MIN_VALUE - 1 == Integer.MAX_VALUE ``` Formally, integer arithmetic in Java is performed **modulo 2^N** (2^32 for int, 2^64 for long): the true mathematical result is reduced into the representable range. This is exact, deterministic, and specified by the Java Language Specification — it is **not** "undefined behavior" the way C signed overflow is. ## Why this matters: it is SILENT The critical, dangerous property is that overflow throws **no exception** and prints **no warning**. The program keeps running with a wrong (often negative) number. Common real bugs: - A loop counter or accumulator that grows past 2.1 billion suddenly goes negative. - `int seconds = days * 24 * 60 * 60;` overflows for large `days`. - Computing a midpoint as `(low + high) / 2` overflows when `low + high` exceeds MAX_VALUE — the famous binary-search bug; use `low + (high - low) / 2`. - Multiplying a count by an element size to allocate memory; an overflowed (small or negative) size leads to a buffer that is too small — a security vulnerability. ## The types involved The wrap rule applies to all the fixed-width integer types: `byte` (8-bit), `short` (16-bit), `char` (16-bit, unsigned), `int` (32-bit), `long` (64-bit). Note that operands smaller than `int` are first **promoted to int** before arithmetic, so `byte + byte` is computed as int and can exceed a byte's range when stored back. `long` has far more headroom (about ±9.2 quintillion) but still wraps. ## How to deal with it 1. **Pick a wider type** when the range can be large (use `long`, or `BigInteger` for unbounded). 2. **Use overflow-detecting helpers**: `Math.addExact`, `Math.subtractExact`, `Math.multiplyExact`, `Math.incrementExact`, `Math.negateExact`, `Math.toIntExact(long)` all throw `ArithmeticException` on overflow instead of wrapping. 3. **Use `Math.floorMod`/`Math.floorDiv`** for correct modulo with negatives, and order computations to avoid intermediate overflow. ## Quick summary Java integer overflow = silent two's-complement wraparound, modulo 2^N, mandated by the JLS. It never throws on its own; you opt into detection.
- What is Integer.MAX_VALUE + 1?Integer.MIN_VALUE (-2,147,483,648) — it wraps to the most negative int.
- How can you make an overflowing addition throw instead of wrap?Use Math.addExact(a, b), which throws ArithmeticException on overflow.
saying these in an interview costs you the question
- Saying Java throws an exception or error on int overflow
- Calling it 'undefined behavior' (that's C, not Java — Java fully specifies the wrap)
- Thinking MAX_VALUE+1 stays at MAX_VALUE (saturation) instead of wrapping to MIN_VALUE
- Believing using long makes overflow impossible (long still wraps, just at a much larger range)