You would need to ask the Java designers to know why they made that design call.
But I expect that it is one or both of the following:
- It is just for consistency with C and C++.
It is because the JLS doesn't directly specify operator precedence. Instead it is emergent from the way that the grammar is specified. As JLS 15.2 says:
"Precedence among operators is managed by a hierarchy of grammar productions."
In other words, it is the structure of the Java formal grammar that determines operator (etc) precedence, not some precedence table. And the Java grammar mirrors the structure of the specification document.
The "official site" you link to in your Question is actually part of the Oracle Java Tutorial. It is a secondary source. The JLS takes precedence.
See also:
- C++ - Why does postfix operator++ have higher precedence than prefix operator++?
- C# - Why does x++ have higher precedence than ++x?
- Wikipedia page on C/C++ Operators.
Here is an example where the operator precedence would make an observable difference:
public static volatile a = 42;
public void busywork() {
while (true) {
++aa--; // ... assuming this was valid Java code ....
}
}
Now create 2 threads, one to call busywork
, and the second to sample the values of a
. You should be able to observe different sets of values for a
, depending on the relative operator precedence; i.e. {41, 42}
with the current rules. If the precedence was the same for post and pre-increment and decrement, then it would be compiler specific whether you saw {41, 42}
or {42, 43}
.
(And of course, having two valid parse trees is going to make life more complicated for the compiler specification and the compiler implementors.)
Finally, it is worth nothing that ++aa--
in the example above is invalid irrespective of the precedence. The increment / decrement operators require an <lvalue>
and evaluate an <rvalue>
, and you can't make the above expression fit those constraints for any ordering or precedence.
Therefore the fact that prefix and postfix forms are described as having different precedence makes no practical difference to programmers.
Maybe the authors of the Java Tutorial could have "simplified" the pre- and post- precedence groups into one group in that (non-definitive) table. They chose not to. You could suggest a correction through the appropriate channels if you were so inclined.