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.

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

From: Eric Blake (e_blake@email.com)
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 ]

A long discussion on Google groups

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 ]

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)

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

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"));

Originally posted by Jose Botella:
An instance of class Object does not holds any data. Thus immutable is not appropiate for it.

mmm. I guess I have to come to the conclusion that any object does not have to be either mutable or immutable then. This seems odd.

Originally posted by Ajith Kallambella:
[i]
the java.lang.Object doesnot represent a very useful class that can hold some data. It is just the primordial class. The word immutable is usually used in the context where there is some data ( content ) involved. Hence E is the wrong answer.
[This message has been edited by Ajith Kallambella (edited August 17, 2000).]

I'm querying if Object is mutable. It might be true that the stored object in the Object reference is mutable or not, but that is irrelevant. What I also see as irrelevant is 'how useful the class is for storing data' - because the fact is it can store data, and therefore the mutable or immutable question stands (can its data be modified or not. probably not).
The way I see it the object class HAS to provide methods to change the value of the object's internal variables. For example changeLetterAtPos(int x, char y) could have done that for String.
So to me it seems that Object is immutable. I can't find a good explanation why it isn't here.
Regards.
[ February 03, 2003: Message edited by: Jim Crawford ]
[ February 03, 2003: Message edited by: Jim Crawford ]

There is nothing here. Nobody uses it. The moderators need to encourage this section for errors, or it will remain worthless.
My opinion.

Originally posted by Shishio San:
y>>x is similar to y>>x%32 if y is in and y>>x%64 if y is long, where x is the number of bits you want to shift with. in your exemple 3>>32 is computed as 3>>32%32 thus 3>>0 and therefore the result is 3.

The remainder operator is quite confusing on this topic. It did seem like an odd rule, but is deducted from the JLS rule. I'd recommend using the normal JLS rule.

how many questions on it in the exam?

I guess there isn't much clarity after all. Its probably just one of those things that are there for people to debate over. Wasn't it fun? (haha)
Sorry I didn't search a real lot, but I've searched other places and I just felt like feeling the water.. or something.
Someone quoted James Gosling out of The Java Language (I think that's what the book is called) where he sort of said its overloading isn't polymorphism. I wish that book was availible online. Spent too much on these kind of books already.
No hard facts here, but who cares. It wouldn't really make a difference to the programs we write right?

Cheers.

Any clarity on this issue? It seems to be something people don't really agree on.
My view is that overloading isn't polymorphism. The term (polymorphism) is sometimes loosely used, but then there is a problem with what it really means.