unprecedented precedence

[Anupreet Arora]

class A {
static boolean a;
static boolean b;
static boolean c;
public static void main (String[] args) {
boolean x = (a = true) || (b = true) && (c = true);
System.out.print(a + "," + b + "," + c);
}
}

The o/p is true,false,false
but i am unable to understand why
does'nt && have higher precedence than ||
how is the expression being evaluated?
Cheers
Anupreet

[cool Tade]

class A {
static boolean a;
static boolean b;
static boolean c;
public static void main (String[] args) {
boolean x = (a = true) || (b = true) && (c = true);
System.out.print(a + "," + b + "," + c);
}
}
The o/p is true,false,false
but i am unable to understand why
does'nt && have higher precedence than ||

Hi,
The evalutaion order is from left to right.
So after (a = true) becomes true the complier doen't evaluates the remaining part of code because of ||(Logical OR opetrator).As remaining experession doesn't get evaluted band c retain the value as false.
Regards
Ankur
(a = true)

[Anupreet Arora]

but i am unable to understand why
does'nt && have higher precedence than ||
should'nt the evaluation be :
((a = true) || ((b = true) && (c = true)));
even if the precedence of && and || is the same
wud'nt the expression be evaluated as :
(((a = true) || (b = true)) && (c = true));

either ways we wudnt get true, false, false.
Secondly, how come an assignment expression (a=true) return true itself?

[Jim Crawford]

Originally posted by Anupreet Arora:
but i am unable to understand why
does'nt && have higher precedence than ||
should'nt the evaluation be :
((a = true) || ((b = true) && (c = true)));
even if the precedence of && and || is the same
wud'nt the expression be evaluated as :
(((a = true) || (b = true)) && (c = true));

either ways we wudnt get true, false, false.
Secondly, how come an assignment expression (a=true) return true itself?

I remember coming across this problem as well.
Go check this out and see if it clears some things up. I'd like to find some JLS clarity on this, but haven't searched very long.
Cheers.

[Doug Lynn]

Originally posted by Anupreet Arora:
but i am unable to understand why
does'nt && have higher precedence than ||
should'nt the evaluation be :
((a = true) || ((b = true) && (c = true)));

Yes, it is. Try it, it returns "true false false". It makes sense to me, but I'll admit I'm hard pressed to come up with a clear explaination of why. Basically, order of operations does not override the rule that expressions are evaluated left to right.
What is clear from the above expression (especially with parens included) is that the right hand side of the || operator is ((b=true)&&(c=true)). The right hand side of the conditional or operator (||) does not get evaluated if the left hand side is true, which it is. Therefore no part of
((b=true)&&(c=true)) gets evaluated.

Originally posted by Anupreet Arora:

Secondly, how come an assignment expression (a=true) return true itself?

(a=true) is itself an assignment expression of type boolean, which evaluates to true, and has the side effect that a gets assigned to true. When I see this (a=true) in an expression I mentally replace it with just true and make a mental note that a now also has the value true. Note that the parens are necessary here as assignment (=) has the lowest precedence of all operators.

[Jose Botella]

The example shows that the short-circuitness of || takes precedence over the higher precedence of &&. In other words: || operator is able to shor-circuit the whole expression to its right.
Consider a brief format of your question: i || j && k The && should be computed before || , but whatever the result of it is, it cannot modify the value of true for i, given that || will be computed after &&.

Let's see this one:

public class Test  {
    boolean i, j, k, m;
    boolean n = i && j && k || m;    
}
//////////////////output of javap -c Test
 Code:
  0:   aload_0
  1:   invokespecial   #1; //Method java/lang/Object."<init>": ()V
  4:   aload_0
  5:   aload_0
  6:   getfield        #2; //Field i:Z
  9:   ifeq    26
  12:  aload_0
  13:  getfield        #3; //Field j:Z
  16:  ifeq    26
  19:  aload_0
  20:  getfield        #4; //Field k:Z
  23:  ifne    33
  26:  aload_0
  27:  getfield        #5; //Field m:Z
  30:  ifeq    37
  33:  iconst_1
  34:  goto    38
  37:  iconst_0
  38:  putfield        #6; //Field n:Z
  41:  return

bytecodes in line 6 : "getfield # 2" pushes into the operand stack the value of i. That is i is evaluated. Then "ifeq 26" jumps to line 26 if the operand stack is 0. At line 26 the evaluation of m is performed. This shows that if i is 0, the first && will not short-circuit the whole of the expression to its right, but only untill the first ||
This behaviour is consistent with the theory. In the expression i && j && k || m; the first two operations should be computed before the third one because && has higher precedence than || . Their operands, however, are evaluated only if the first && does not short-circuit.

[Anupreet Arora]

Thanks guys for the wonderful explanation... but I was kind of hoping for some JLS or some other reference to support the following result as told by Jose
" The example shows that the short-circuitness of || takes precedence over the higher precedence of &&. In other words: || operator is able to short-circuit the whole expression to its right "
So It would be a big help if someone could back up this justification of the behaviour exhibited in the above examples, by some textual reference.
Thanks & Regards,
Anupreet

[Alton Hernandez]

does'nt && have higher precedence than ||

Yes, you are right, && has a higher precedence than ||. That is why the expression
boolean x = (a = true) || (b = true) && (c = true);
should be read as :
(a = true) || ( (b = true) && (c = true) )
Because that is what precedence means - it tells you how to add the parentheses, NOT the order of the evaluation.

how is the expression being evaluated?

The order of evaluation will be from left to right. So the expression (a=true) will be evaluated first. And since the operator || is short-circuited, it will not continue with the remaining expressions, leaving the variables b and c unchanged. So that is why you will get the result of true, false, false.
[ August 19, 2003: Message edited by: Alton Hernandez ]

[Anupreet Arora]

This is a cool interpretation of the problem at hand. It kind of sorts out the issue!
Its like 5+1*3 = 5 + (1*3) so first of all, you take 5 as the operand. The operator next to it says that you need another operand. so it evaluates (1*3) and performes the operation to return 8. If in another expression the operator was sth like ||, it would have said, "Thats it ! the issue is resolved... Short circuit now ", just after the evaluation of the left hand operand. And this explains the behaviour
Cheers!
Anupreet