Order of evaluation with logical operators

[Winston Gutkowski]

Winston Gutkowski wrote:...so some sort of evaluation is needed to make sure that the type of rvalue is correct.

Dang! Now I'm mixing compile-time with runtime....

Don't worry. I've basically got it now (I think ). Thanks guys.

Winston

[Liutauras Vilda]

Roel De Nijs wrote:

int i = 5;
int j = 10;
System.out.println(++i + --i * --j);

This code snippet prints 51. Because it's evaluated as 6 (++i), 5 (--i) * 9 (--j) and finally 6 + 45.

This example is extremely good. Merits a cow. Actually two.

It simply reveals, that operators precedence does the grouping of operands, but does not define the evaluation order of whole expression. Really liked it.

[Henry Wong]

Winston Gutkowski wrote:

Winston Gutkowski wrote:...so some sort of evaluation is needed to make sure that the type of rvalue is correct.

Dang! Now I'm mixing compile-time with runtime....

Yeah, it *is* a pain. Discussions (of this type) regarding Precedence, Associativity, and Evaluation Order, should be in the context of the compiler (and compile time)... but "evaluation" is incredibly difficult to not use the context of runtime.

I do it too, I am looking out for it...

Henry

[Roel De Nijs]

Winston Gutkowski wrote:

Winston Gutkowski wrote:...so some sort of evaluation is needed to make sure that the type of rvalue is correct.

Dang! Now I'm mixing compile-time with runtime....

Glad to see you noticed that one yourself. That saves me a reply

And honestly I think you are overcomplicating this a little bit, while it is so easy and simple:
1/ at compile time the compiler executes a (static) code analysis to verify if you met all syntax rules (e.g. both operands of the operators && and || must evaluate to a boolean or Boolean value).
2/ at runtime the right operand might not be executed if and only if the result is already known after evaluating the left operand (e.g. false && ... will always evaluate to false; true || ... will always evaluate to true).

And with the ternary operator, the behavior is similar:
1/ the compiler will check if the condition evaluates to a boolean (or Boolean) value and also verifies if the true- and false-expressions are compatible with the type of the variable to which the result is assigned.
2/ at runtime the condition is evaluated (executed) and based on its result only the true- or the false-expression is evaluated (executed).
This is illustrated in this code snippet

int i = 5;
StringBuilder sb = null;
Object o = (args.length>0) ? sb.toString() : 10;
Serializable s = (i > 10) ? sb.toString() : 10;
Comparable<? extends Serializable> c = (args.length>0) ? sb.toString() : 10;
System.out.printf("%s %s %s%n", o, s, c);

Output: 10 10 10 (and no NullPointerException is thrown)

But these will not compile, because the types of the true- and false-expressions are not compatible with the variable type

Comparable<Serializable> c0 = (args.length>0) ? sb.toString() : 10;
Comparable<String> c1 = (args.length>0) ? sb.toString() : 10;
String s0 = (args.length>0) ? sb.toString() : 10;
Integer i0 = (args.length>0) ? sb.toString() : 10;

Kind regards,
Roel

[Winston Gutkowski]

Roel De Nijs wrote:And honestly I think you are overcomplicating this a little bit, while it is so easy and simple:

For a self-professed "human compiler" maybe; but plainly not for the rest of us mortals.

In my case, I had it wrong for more than a dozen years; but it's never caused me any problems because I simply don't write expressions that rely on the "effects" of sub-expressions (beyond '.' chaining of course).

And I still say that the JLS only adds to the confusion, because its narrative is far from clear.

Winston

[Roel De Nijs]

Winston Gutkowski wrote:For a self-professed "human compiler" maybe; but plainly not for the rest of us mortals.

When you are active in this forum for a few years and having reviewed some OCA study guides, you'll automatically become a "human compiler"

Winston Gutkowski wrote:And I still say that the JLS only adds to the confusion, because its narrative is far from clear.

If you see which kind of language is used to write the JLS, I think adding confusion is its main purpose

[Cedric Bosch]

I think some of the replies are a bit confusing so here is my take.

First of all this :

System.out.println( (a=false) && (b=true) | (c=true) );

Can be rewritten as this:

System.out.println( false && true | true );

It's only an assignment that returns the value assigned. Here is another simpler example :

int i;
System.out.println( (i = 13) ); // All we do is assigning 13 to the value i and returning it.
// Thus that can be rewritten as:
System.out.println(13);

With that out of the way you can see that this :

System.out.println( (false && true | true ); // Since bitwise operations have precedence this is always false ie => (false) && (true | true) => false && true

[Liutauras Vilda]

Cedric Bosch wrote:First of all this :

System.out.println( (a=false) && (b=true) | (c=true) );

Can be rewritten as this:

System.out.println( false && true | true );

I disagree.

Execute this example and you'll see:

boolean a = false;
boolean b = false;
boolean c = false;
System.out.println(a=false && (b=true) | (c=true));
System.out.println("a: " + a);
System.out.println("b: " + b);
System.out.println("c: " + c);

Output:

false
a: false
b: false
c: false

While you're stating output should be:

false
a: false
b: true
c: true

[Liutauras Vilda]

Cedric Bosch wrote:System.out.println( (false && true | true ); // Since bitwise operations have precedence this is always false ie => (false) && (true | true) => false && true

That explanation is also incorrect, even though the output is false.

[Liutauras Vilda]

false && true | true

Expressions in Java being evaluated from left to right always.
&& operator is so called short-circuit. That means, no matter what is the operand on the right hand side - if left side can define that whole expression going to be false, that means, right operands not getting evaluated at all.

If expression were:

true && false | true

the expression behind the scenes would be treated as a visual example below.

Going to be:

true && (false | true)

true && true

Rather than:

(true && false) | true

false | true

[Cedric Bosch]

I need to read the whole thread because I'm confused right now. In the mean time can someone tell me what's a cow ? I see every one is saying "here have a cow".

[Roel De Nijs]

Cedric Bosch wrote:With that out of the way you can see that this :

System.out.println( (false && true | true ); // Since bitwise operations have precedence this is always false ie => (false) && (true | true) => false && true

You are completely incorrect!

First of all, you can't rewrite

System.out.println( (a=false) && (b=true) | (c=true) );

as

System.out.println( false && true | true );

because both statements are not equivalent at all. These are two completely different statements.

Secondly your understanding of how the evaluation of the following statement occurs, is completely wrong as well

System.out.println( (a=false) && (b=true) | (c=true) );

In Java, expression are always evaluated from left to right (except for the assignment operator which is evaluated from right to left). That means that (a=false) is the first expression to be evaluated. It obviously evaluates to false. Because the left-hand side of the short-circuit && operator evaluates to false, the right-hand side ((b=true) | (c=true)) will not be evaluated at all.
And that is clearly illustrated in this code snippet

boolean a = false, b = false, c = false;
boolean res = a=false && (b=true) | (c=true);
System.out.printf("res:%b a:%b b:%b c:%b", res, a, b, c);

Output: res:false a:false b:false c:false

Hope it helps!
Kind regards,
Roel

[Roel De Nijs]

Cedric Bosch wrote:In the mean time can someone tell me what's a cow ? I see every one is saying "here have a cow".

Have a look at the Ranch Cows article to learn everything you need to know about cows You can compare it a bit with a Facebook thumbup on steroids

[Cedric Bosch]

Roel De Nijs wrote:Secondly your understanding of how the evaluation of the following statement occurs, is completely wrong as well

Oooh, I see my error. Yes it does help and thanks for pointing me in the right direction, I was inverting the meanings of & and &&. So one operator let's it go through and two doesn't.

So this :

false && true | true 

can be thought as this :

(a=false) &&..Whatever it's not gonna be evalutated

And this :

 false & true | true 

can be thought as thought as :

false & (true|true)

I hope that's correct ?

And my first statement would have been correct if there was only one & (I suppose) :

        boolean a = false;
        boolean b = false;
        boolean c = false;
        System.out.println((a=false) & (b=true) | (c=true));
        System.out.println("a: " + a);
        System.out.println("b: " + b);
        System.out.println("c: " + c);

Output :

true
a: false
b: true
c: true

[Roel De Nijs]

Cedric Bosch wrote:I hope that's correct ?

And my first statement would have been correct if (I suppose) :

Yes, both are correct!

So one little additional character can make a huge difference, as illustrated in these code snippets

public void process(String s) {
	if (s != null && s.length() > 0) {
		// do stuff
	}
}

public void process(String s) {
	if (s != null & s.length() > 0) {
		// do stuff
	}
}

And then invoke both methods with a null value and see what happens

Hope it helps!
Kind regards,
Roel

[Cedric Bosch]

It will throw an error on the second one :p. NPE
I'd give you a cow if I could (the link you gave me say it's only one cow per day for rancher and I'm only rancher hand:)).

[Liutauras Vilda]

@Cedric
You just got your first cow for a nicely solved problem well done

[Cedric Bosch]

Liutauras Vilda wrote:
You just got your first cow for a nicely solved problem well done

Awesome, I'm part of the pack now !