Simple precedence question.

[Jim Crawford]

The way I understand it && has a greater precedence than ||.
So what would the output be here?

  boolean booleanResult(boolean value, 
String flag)
  {
    System.out.println(flag);
    return value;
  }

  System.out.println(booleanResult(true, "A") ||
      booleanResult(true, "B") &&
      booleanResult(true, "C"));

[Jim Crawford]

I'll probably be kicked to the biginner corner again for this easy question, but I don't see why the above doesn't print:
B
C

[Valentin Crettaz]

No I won't kick you to the beginner forum since this question is interesting on the SCJP point of view.
Let's dig into it.
Actually the code example you give boils down to the following expression:
A || B && C
(whether A, B and C are boolean primitive variables, boolean literals or boolean-returning methods is not important.)
Java evaluates expression from the left to the right respecting the precedence order. In this case, when the runtime starts evaluating this expression it sees that it has to deal with a || (short-circuit OR) operation. It also sees that the first operand is A and the second is, well, it doesn't need to know that until A has been evaluated. When starting the evaluation of the expression what the runtime sees is
A || ??
If the runtime finds out that A evaluates to false, then it will investigate further and evaluate the second operand which is B && C. But in this case, the runtime figures out that B is true and that there is thus no need to go further. That's why only A gets printed out.
[ February 07, 2003: Message edited by: Valentin Crettaz ]

[Jim Crawford]

I suspected something along these lines, but I fail to see the role that precedence plays then...
I can understand that this is possible as an optimization, but isn't it true that the || should be ignored until the && is complete?
I could be missing the point (and didn't have much sleep last night)

[Valentin Crettaz]

Could you please take a look at the following document and tell me if it is of any help:
http://www.atkinson.yorku.ca/~sychen/ITEC1620/Tutorial3.pdf
Java performs what we call automatic binding, that is, the following expression
A && B || C && D
will be evaluated as
(A && B) || (C && D)
and not as
A && (B || (C && D))
or as
A && (B || C) && D
In our case, A || B && C will be evaluated as
A || (B && C) but since || is a short circuit the second operand never gets evaluated if A is true.
[ February 07, 2003: Message edited by: Valentin Crettaz ]

[Jim Crawford]

I found a possible answer in this thread.
I guessed I missed it in the JLS etc. No doubt that it could be hidden there somewhere. Will look at the PDF now as well. Thanks.

import java.lang.*;
public class test1
{
    public static void main( String args[] ) {
    int i=3;
    int a=0;
    if (i == 3 | | ( (a=i) > 2) ) {
       System.out.println("value of a : "+ a);
    int b = 3 ;
    System.out.println( b < 4 && 2+3 > 0 ) ; 
    }  // end of if
}  // end of main
}  // end of class

1. in the 1st if statement. the order of evaluation review the left poriton of the
short circuit OR first. then, the short circuit OR is evaluated. followed by
any statements after the short circuit OR. the point being. for both && and | |,
the statement to the left are evaluated before operator precedence is applied.
since the left operator is TRUE. the operator to the right of | | is never evaluated. the operator to the right of && will always be evaluated.
2. ie.
b is three
b is less than 4
therefore the first statment is TRUE
2+3 is 5
5 is greater than 0
therefore the second statemend is TURH
the answer is TRUE
Hope this clears things up.
Monty
<hr></blockquote>
[ February 07, 2003: Message edited by: Jim Crawford ]

[Jim Crawford]

A long discussion on Google groups

[Jim Crawford]

I think this is the story (although there was a part about grammer that looked interesting as well)

From: Eric Blake ([e-mail])
Subject: Re: Operator Precedence
View: Complete Thread (20 articles)
Original Format
Newsgroups: comp.lang.java.programmer
Date: 2001-04-13 19:21:30 PST
"Scott D. Isaac" wrote:
> ..
> 12. Short-circuit: &&
> 13. Short-circuit: || ..
>
> However, I have found the JLS (section 15) to be vague about precedence.
> While this is the order in which they are presented, there is no mention
> that that is the order of precedence.
It is explicitly stated within the grammar of chapter 15, but is lacking
in the grammar of chapter 18, as well as the descriptive text of chapter
15. Hopefully the 3rd edition JLS will rectify this and make the
chapter 18 grammar express precedence, as well as describe it better in
the description.
>
> So, what's my beef you ask?
>
> Through experimentation, I have found that 12 and 13 are at the same level
> of precedence. This contradicts what I have seen written and the JLS is
> silent on this matter.
The difference in precedence is observable when the first term evaluates
as true.
With (a||b)&&c, c must be evaluated if a is true. However, with
a||(b&&c), the entire (b&&c) term is never evaluated, because ||
short-circuits.
So, if || and && have equal precedence, a||b&&c is equivalent to
(a||b)&&c, since they group left-to-right; you would get a side-effect
from evaluating c in 6 of the 8 input cases, and a true result in only 3
of the 8.
However, since && has a higher precedence, a||b&&c is equivalent to
a||(b&&c), and you only get a sige-effect from c in 2 of the 8 input
cases, and a true result in 5 of the 8.
Here's a program to print out all the cases.

class Test {
  static boolean b(boolean b, char c) {
    System.out.print(c + " ");
    return b;
  }
  public static void main(String[] args) {
    for (int i=0; i<8; i++) {
      System.out.print((i>3) + " " + ((i&3)>1) + " " + ((i&1)>0));
      System.out.print('\t');
      // test a || b && c
      System.out.print( b(i>3,'a') || b((i&3)>1,'b') && b((i&1)>0,'c')
);
      System.out.print('\t');
      // test (a || b) && c
      System.out.print((b(i>3,'a') || b((i&3)>1,'b'))&& b((i&1)>0,'c')
);
      System.out.print('\t');
      // test a || (b && c)
      System.out.print( b(i>3,'a') ||(b((i&3)>1,'b') &&
b((i&1)>0,'c')));
      System.out.println();
    }
  }
}

This program outputs (with some post-formatting applied):
false false false a b false a b false a b false
false false true a b false a b false a b false
false true false a b c false a b c false a b c false
false true true a b c true a b c true a b c true
true false false a true a c false a true
true false true a true a c true a true
true true false a true a c false a true
true true true a true a c true a true
--
Eric Blake

[ February 07, 2003: Message edited by: Jim Crawford ]

[Jim Crawford]

Summary:
You can express precedence with brackets:
thus
a || b && c
becomes
a || (b && c)
which is easy to understand.
The || still gets executed first and the brackets illustrate what is done according to precedence.
Just like Valentin said, but I didn't make the connotation immediately.
Cheers.

[Valentin Crettaz]

Happy you got it

[bart zagers]

Thanks,
I struggled with the same problem, but now I finally got it.
Bart

[Jose Botella]

I agree we could say && has a greater precedence than ||. But we must be aware of the code that the compiler generates. Because if someone thinks that a||b&&c will be treated as a||(b&&c) there is a problem: even though both will yield the same result, if the evaluation of b and c has side effects, they will not happen.
The point is that || and && will not short-circuit the same part of the remaining expression.
If the expression consist of a serie of && a || operators with no interwined parentheses the output of javap shows the following two points:
a) A true value before || will short-circuit the whole of the remaining expression. Thus no remaining side effects will occur. It is funny to say that remaining && operators have a greater precedence because their operands are not evaluated at all.
b) A false value before && will short-circuit only up to the left operand of the first || to its right. Thus side effects are possible starting from the right operand of the cited ||.
I guess this difference in the implementations of the two operators allows for the "strange" bigger precedence of && over ||.
Here goes the code produced by the compiler for two examples:

/* result = a && b && c && d || e || f
Method static {}
   0 getstatic #2 Field boolean a
   3 ifeq 24
   6 getstatic #3 Field boolean b
   9 ifeq 24
  12 getstatic #4 Field boolean c
  15 ifeq 24
  18 getstatic #5 Field boolean d
  21 ifne 36
  24 getstatic #6 Field boolean e
  27 ifne 36
  30 getstatic #7 Field boolean f
  33 ifeq 40
  36 iconst_1
  37 goto 41
  40 iconst_0
  41 putstatic #8 Field boolean result
  44 return
*/
/*result = a || b || c || d || e && f;
Method static {}
   0 getstatic #2 Field boolean a
   3 ifne 36
   6 getstatic #3 Field boolean b
   9 ifne 36
  12 getstatic #4 Field boolean c
  15 ifne 36
  18 getstatic #5 Field boolean d
  21 ifne 36
  24 getstatic #6 Field boolean e
  27 ifeq 40
  30 getstatic #7 Field boolean f
  33 ifeq 40
  36 iconst_1
  37 goto 41
  40 iconst_0
  41 putstatic #8 Field boolean result
  44 return
*/

Note that the real values of the variables will not matter to the code generated by the compiler; at least in this case.
Waiting for comments