What is the difference between prefix and postfix increment/decrement (++x vs x++) in Java?
answer
- prefix ++x: increment THEN return new value
- postfix x++: return old value THEN increment
- standalone x++ == ++x
- i = i++ leaves i unchanged (trap)
- works on numeric vars incl char; implicit cast back
- Java = strict left-to-right (defined, unlike C)
basics
~20 sBoth add 1 to the variable. The difference is the value the expression gives: ++x increments first and returns the new value; x++ returns the old value and then increments. Used alone on a line they behave the same.
solid answer
~50 s++ and -- change a variable by 1. In prefix form (++x), the variable is incremented and the expression evaluates to the new value. In postfix form (x++), the expression evaluates to the original value and the increment happens afterward. As a standalone statement (x++;) there is no difference. The distinction matters when the operator is part of a larger expression: int a = 5; int b = a++; leaves a == 6, b == 5, whereas int b = ++a; leaves both 6. A classic trap is i = i++; the postfix yields the old value of i and assigns it back, so i stays unchanged. Increment/decrement only apply to mutable numeric variables (not literals or final fields), they implicitly perform the narrowing back to the variable's type (so they work on byte/short/char without a cast), and Java evaluates operands strictly left to right, which makes expressions like a++ + a++ well-defined (unlike in C).
code
java · 15 linesint a = 5;
int b = a++; // b = 5 (old), then a = 6
System.out.println(a + " " + b); // 6 5
int c = 5;
int d = ++c; // c = 6 first, then d = 6
System.out.println(c + " " + d); // 6 6
int i = 0;
i = i++; // classic trap: i stays 0
System.out.println(i); // 0
byte by = 1;
by++; // legal: implicit narrowing back to byte
System.out.println(by); // 2go deeper
States that ++x returns the new value and x++ returns the old, and that alone on a line they're the same.
Traces b = a++ vs ++a correctly and explains the i = i++ trap and the implicit narrowing for byte/char.
Adds Java's guaranteed left-to-right evaluation (deterministic unlike C) and argues for keeping increments out of complex expressions for readability.
Treats embedded side-effecting increments as a code-review smell and sets readability/clarity conventions; understands the spec-level evaluation-order guarantees.
## The two operators `++` is the **increment** operator (add 1); `--` is **decrement** (subtract 1). Each comes in two positions: - **Prefix**: the operator before the variable — `++x`, `--x`. - **Postfix**: after the variable — `x++`, `x--`. Both ultimately change the variable's value by 1. The difference is **the value the expression itself produces** (its *result*), which only matters when the increment is used as part of a bigger expression. ## The core rule - **Prefix `++x`**: increment first, then the expression's value is the **new** (incremented) value. - **Postfix `x++`**: the expression's value is the **old** (original) value, and the increment happens afterward. Walk through it: ``` int a = 5; int b = a++; // b gets the OLD value 5; then a becomes 6 // now a == 6, b == 5 int c = 5; int d = ++c; // c becomes 6 first; d gets the NEW value 6 // now c == 6, d == 6 ``` As a **statement by itself**, `x++;` and `++x;` are identical — nobody reads the result, so 'old vs new value' is invisible. The difference only surfaces inside assignments, method arguments, array indexing, loop conditions, etc. ## The classic self-assignment trap ``` int i = 0; i = i++; // i is STILL 0 ``` Why: `i++` first produces the old value `0` (and schedules `i` to become `1`). But then the assignment `i = ...` writes that captured `0` back into `i`, overwriting the increment. Net effect: `i` stays `0`. This bug appears constantly in puzzles. (Use `i++;` on its own line, or `i = i + 1;`.) ## Where they apply and what they require - They work only on a **mutable variable, array element, or non-final field of a numeric type** (including `char`) — not on a literal (`5++` is illegal) nor a `final` variable. - They **implicitly cast back** to the variable's type, so `byte b = 1; b++;` compiles even though `b + 1` would normally be `int`. That's a convenience these operators provide. - For `char`, `++` moves to the next code point: `char ch = 'a'; ch++;` makes `ch == 'b'`. ## Java is deterministic here (unlike C) Java specifies **strict left-to-right evaluation** of operands and that side effects of a subexpression complete before the next operand is evaluated. So `int a = 1; int r = a++ + a++;` is well-defined: first `a++` yields 1 (a becomes 2), then `a++` yields 2 (a becomes 3), so `r == 3` and `a == 3`. In C/C++ this would be undefined behaviour; in Java the answer is guaranteed. Even so, putting multiple increments of the same variable in one expression is poor style — write it out for readability. ## Practical guidance Prefer the postfix form in `for` loops (`for (int i = 0; i < n; i++)`) by convention; the result is discarded so it doesn't matter, but it's the idiom. Avoid embedding `++`/`--` inside larger expressions where the old-vs-new distinction is load-bearing — it's a frequent source of confusion in reviews.
- After `int x = 3; int y = x++ + ++x;`, what are x and y?x++ yields 3 (x becomes 4); ++x makes x 5 and yields 5; so y = 3 + 5 = 8 and x = 5. Java's strict left-to-right evaluation makes this deterministic.
- Why does `b++` compile for a byte while `b = b + 1` may not?b + 1 promotes b to int, producing an int that needs an explicit cast to fit back into a byte. The ++ operator includes an implicit narrowing conversion back to the variable's type, so byte/short/char work without a cast.
saying these in an interview costs you the question
- Saying ++x and x++ always behave identically (true only as a standalone statement)
- Expecting `i = i++` to increment i
- Thinking the result of x++ is the new value
- Believing a++ + a++ is undefined in Java (it is well-defined, left-to-right)
- Trying to apply ++ to a literal or final variable