Java Operator Precedence and Associativity: Complete Evaluation Order

Precedence problems are easier to reason about once you split them into two separate ideas. **Precedence** decides which operator grabs an operand first, so it only matters when two different operators compete. **Associativity** decides the grouping when two operators of *equal* precedence compete, and it applies only within a single level.

precedence which operator binds tighter 2 + 3 * 4 -> 2 +(3 * 4), because * is higher associativity which of two equal operators goes first 100 / 10 / 5 ->(100 / 10) / 5, because / is left-associative

The practical consequence is that precedence questions are about the table below, while associativity questions only ever arise inside a single row of it.

int a = 10 + 5 * 2;
// precedence: * first, so 20
int b =(10 + 5) * 2;
// parentheses: 30
int c = 100 / 10 / 5;
// associativity: left to right, so 2

This is the whole table, from highest to lowest. Numbering from the top is the usual convention, and reading it bottom-up is how the compiler reads it.

Three entries deserve comment. instanceof sits at the relational level, not the type level, which is why it competes with < rather than with the cast operator. The cast operator binds *looser* than the prefix unary operators, so -x is (-x) and not -(x) in the way you might guess. And the lambda arrow is the lowest operator in the language, below assignment.

highest postfix ++ expr-- arr[i] obj.field method() unary ++ -- + - ~ ! cast(type) ... lowest lambda -> the table is read top to bottom for tightest to loosest binding

This ordering trips up developers arriving from C, where & binds tighter than the equality operators. In Java the bitwise operators are *below* equality.

System.out.println(true == true & false);
// false

Read it carefully and the result makes sense only one way. == is higher than &, so this groups as (true == true) & false, which is true & false, which is false. If & bound tighter the expression would be true == (true & false) and the answer would be false as well, which is why this example is a poor demonstration. The boolean XOR version separates them cleanly.

boolean p = true, q = false;
System.out.println((p | q) == true);
// true, with parens
System.out.println(p ^ q);
// true

The safe habit is to parenthesise whenever &, | or ^ appears in a condition, precisely because the precedence surprises people. These operators also do **not** short-circuit, so nullable != null && list.get(0).isEmpty() is the right form and nullable != null & list.get(0).isEmpty() throws.

// & does not short-circuit, so the right operand is always evaluated
String s = null;
System.out.println(s != null & s.isEmpty());
// throws NullPointerException

Shift operators sit at level 6, below additive, which produces a genuinely surprising result for anyone assuming shifts bind tightly.

System.out.println(1 + 2 > 1 + 1);
// 2

The first line is (1 + 2) << 3, that is 3 << 3, which is 24. The second is 8 >> (1 + 1), that is 8 >> 2, which is 2. Both are low-precedence operations on a sum, which is the opposite of the intuition that a shift is a low-level arithmetic operation.

The classic consequence is the unsigned-shift gotcha on a negative value.

System.out.println(-1 >>> 0);
// -1, not a large positive number
System.out.println(-1 >> 0);
// -1, the sign is preserved
System.out.println((-1 >>> 0) + 1);
// 0

-1 >>> 0 looks like it should produce a large unsigned value, but the result is still -1, and widening does not change that.

System.out.println(-1 >>> 0);
// -1
System.out.println(-1L >>> 0);
// -1, still, and the cast is not the issue
System.out.println(Long.toHexString(-1L >>> 0));
// ffffffffffffffff

The reason is that a shift count of 0 is an **identity**: shifting by zero positions returns the value unchanged, unsigned or not. The hex output shows all sixteen bits still set, which is what -1 is in two's complement.

System.out.println(-1L >>> 1);
// 9223372036854775807, now the top bit really does go
System.out.println(-1L >>> 32);
// 4294967295
System.out.println(-1L >>> 60);
// 15

So if you want to reinterpret a signed value as unsigned, a shift by zero is never the tool. Use a nonzero shift, or ask for the unsigned text directly.

System.out.println(Long.toUnsignedString(-1L));
// 18446744073709551615
System.out.println(Integer.toUnsignedLong(-1));
// 4294967295

Level 5 is not just addition. The + operator becomes string concatenation as soon as either operand is a String, and because the level is left-associative the operand that comes first decides what happens.

System.out.println(1 + 2 + "3");
// "33"
System.out.println("3" + 1 + 2);
// "312"

These two are the classic demonstration. In the first, the leftmost operation is 1 + 2, giving the number 3, which then concatenates with "3" to give "33". In the second, the leftmost operation is "3" + 1, giving the string "31", which then concatenates with 2 to give "312". Addition and concatenation are the same operator, so the grouping decides which one you get.

System.out.println(1 + 2 + 3 + "4");
// "64", the numbers add first
System.out.println("n = " + 1 + 2);
// "n = 12", both then concatenate

The fix is an explicit parenthesis or a local variable when mixing the two.

System.out.println(1 +(2 + "3"));
// "123", so parens alone do not add the numbers
int sum = 1 + 2;
System.out.println(sum + "3");
// "33", with the arithmetic named

Parentheses control the grouping but cannot change the fact that the outer + still concatenates. The only way to get arithmetic is to perform it where both operands are numbers, which means extracting the sum into a variable or writing a separate statement.

This also explains the confusing ternary output from the previous topic. "value: " + 5 + (true ? 1 : 2) produces text beginning 51, because the + chain consumes everything to its right before the ternary is ever consulted.

Every binary arithmetic, relational, equality, bitwise and logical operator is left-associative. The rule is simple to state and its consequences are not always obvious.

System.out.println(2 - 3 - 4);
// -5, that is (2 - 3) - 4
System.out.println(100 / 10 / 5);
//  2, that is (100 / 10) / 5
System.out.println(2 * 3 % 4);
//  2, that is (2 * 3) % 4

Subtraction and division are not associative, so the grouping changes the answer. This is the single most useful thing to internalise, because writing a / b / c when you meant a / (b / c) is a bug that compiles cleanly.

2 - 3 - 4 left assoc(2 - 3) - 4 = -5 2 -(3 - 4) 2 -(-1) = 3 a different answer 100 / 10 / 5 left assoc(100 / 10) / 5 = 2 100 /(10 / 5) 100 / 2 = 50 a different answer

Shifts are left-associative too, which surprises people because shifts are often assumed to be right-associative by analogy with exponentiation.

System.out.println(1

Three groups are right-associative: the prefix unary operators, the ternary, and assignment. Each has a purpose the left-associative form could not serve.

Assignment is right-associative so that chained assignment works, and this is what makes declaring several variables of the same type on one line legal.

int x, y, z;
x = y = z = 100;
System.out.println(x + " " + y + " " + z);
// 100 100 100

The rightmost assignment happens first, so z is set, then y is set to the result, then x. Each variable receives the same value because the assignment expression evaluates to the value assigned.

The ternary is right-associative, which gives the threshold ladder its natural reading direction.

int score = 85;
String grade = score >= 90 ? "A" : score >= 80 ? "B" : "C";
// "B"

That groups as score >= 90 ? "A" : (score >= 80 ? "B" : "C"), so the best grade is checked first. The reverse nesting is legal and unreadable.

The prefix unary operators are right-associative, which is why a stack of ! or ~ unwinds from the right.

System.out.println(!!true);
// true
System.out.println(~~5);
// 5, applying it twice is the identity

Note that the compound assignment operators share this level, so a += b += c also evaluates right to left, with b updated first.

Parentheses sit above every operator, so they override precedence completely. This is the only mechanism for expressing a grouping the table would not choose.

int a = 10 + 5 * 2;
// 20
int b =(10 + 5) * 2;
// 30
int c = 10 +(5 * 2);
// 20, redundant but harmless

The cast operator binds looser than the prefix unary operators, so -x applies the negation to the cast value rather than the other way round. This matters for integer division and narrowing.

int i = -7;
System.out.println(-i / 2);
// 3, that is (-7) / 2
System.out.println(i / -2);
// 3, by the same rule
System.out.println(-i % 2);
// 1, because the negation applies first

A parenthesised expression cannot be the target of an increment, because increment needs a *variable*, and parentheses turn a variable into a value.

int j = 5;
int r =(-j)++;
// error: unexpected type

The same rule is why the final keyword blocks increment. Reading a final field yields a value rather than a variable, and the increment operators need a variable.

final int k = 5;
// k++;    error, a final variable cannot be incremented

Postfix sits at the top of the table and prefix one level below, so in a combined expression the two increment forms behave differently. The difference is not precedence but *when* the increment is applied relative to the value produced.

int x = 5;
System.out.println(x++ + ++x);
// 12, and x ends at 7

Postfix yields the old value and increments afterwards, while prefix increments first and then yields the new value. In that expression the x++ yields 5 and leaves x at 6, then ++x raises it to 7 and yields 7, giving 12.

Postfix binds tighter than unary, which is visible in an index expression.

int[] arr = {
    0, 1, 2
};
int i = 0;
int v = arr[i++];
// 0, arr[0] is read before i becomes 1
System.out.println(v + " " + i);
// 0 1
i = 0;
int w = arr[++i];
// 1, i becomes 1 before the read
System.out.println(w + " " + i);
// 1 1

Reading the same variable twice in one expression is legal, and deterministic, but hard to read. Use separate statements.

Java does not support 1 < 2 < 3. The first comparison produces a boolean, and a boolean cannot be compared with an int, so the expression is rejected.

System.out.println(1 < 2 < 3);
// error: bad operand types for binary operator '

This is a genuine improvement on languages that allow it, because even if it compiled it would be wrong. The grouping would be (1 < 2) < 3, and comparing a boolean with 3 is meaningless. Write the two comparisons explicitly.

int value = 5;
System.out.println(0 < value && value < 10);
// true

A related trap is the classic "unrolled" C idiom, which Java rejects for the same reason.

// invalid in Java
// if (low

Precedence and associativity decide the *structure* of an expression. They do not decide the order in which subexpressions run, and that is a separate rule in the language.

Operands of a single operator are evaluated left to right, and so are the arguments of a method call.

static int c = 0;
static int mark() {
    c++;
    return c;
}System.out.println(mark() + mark() + mark());
// 6, that is 1 + 2 + 3

The calls happen left to right even though + is associative, and the same rule applies to method arguments.

System.out.println(mark() + " " + mark());
// the first mark runs first

The left-hand operand of an assignment is evaluated before the right, which matters when it has side effects of its own.

int[] data = new int[3];
int idx = 0;
data[idx++] = idx;
// the element and the value are not independent
System.out.println(data[0] + " " + data[1] + " " + idx);
// 1 1 1

The assignment evaluates its left operand first, so data[0] is selected and idx becomes 1, and only then is the right side read as 1. That single write lands the value in slot 0, which is worth knowing before you write this shape on purpose.

The practical takeaway is that short-circuit operators change evaluation order deliberately. In a != null && a.isEmpty(), && guarantees the right operand is skipped when the left is false, and that guarantee is the entire reason to use it instead of &.

String s = null;
System.out.println(s != null && s.isEmpty());
// false, no exception
System.out.println(s != null & s.isEmpty());
// throws NullPointerException

Chained calls look like they might be governed by precedence, but they are not. Each call returns a value, and the next call is applied to that value, so the order is determined by the types rather than by the table.

StringBuilder sb = new StringBuilder();
sb.append(1).append("x").append(2);
System.out.println(sb);
// 1x2
System.out.println(sb.length());
// 3

The chain works only because every intermediate call returns something the next can be called on. Break the chain and it stops compiling, which is a good property, since it means the type of each link is checked rather than discovered at run time.

String s = "abc";
System.out.println(s.length());
// fine, length() returns int
// System.out.println(s.length().length()); // error: int cannot be dereferenced

If you remember only one thing, make it the parentheses rule. Precedence is a table you can look up, associativity is a habit you can verify, but explicit parentheses cost nothing and remove the entire class of bug. Every expression involving subtraction, division, a shift, a bitwise operator, or a + next to a String is a candidate for parens, and the cases where you leave them out should be the ones where you have already confirmed the grouping.