I assume that you all know about the unsigned right shift operator in Java

You'd all know that the positive decimal integer 2 is represented in binary as 10.

Therefore 2 would be represented in binary as 00000000 00000000 00000000 00000010 in a 32 bit integral type.

If you refer any book on Java ,the operator >>> would be superficially defined as
It shifts the bits on the left, by number of position to the right as specified by the operand on the right side, not preserving the sign.

So ,
2 >>> 1 would obviously result in 1 .
2 >>> 2 returns 0 (because it's shifted twice, and only there's 0 that remains)

Therefore for any other value on the right side greater than 2, it would result in 0.
2 >>> 3 returns 0
2 >>> 4 returns 0
2 >>> 67 returns 0
2 >>> 101 returns 0
2 >>> 1045 returns 0

So, you think the piece of code shown below is correct?

Code snippet 1:

if ( 2 >>> someIntegerValue == 0 ) {
System.out.println("Hey dude! I can assure you that the operand on the right side is definitely greather than or equal to 2");
} else {
System.out.println("The operand on the right side is definitely less than 2");
}

But when you run the program, for some values of someIntegerValue (for some valus greater than 2), it does not return 0.
Well, I'll tell you. 32, 33, 64, 65 ...

Why?

If for upto 31 it returns 0, why for 32 would it return 2? What happens exactly?

Give me a proper explanation as to why does this happen.
(Don't tell me that the size of integer is 32 in Java , and every multiple of 32 is considered as 0. Well, that's right actually. But that's not the explanation I'm looking for).

``````Code snippet 1:

if ( 2 >>> someIntegerValue == 0 ) {
System.out.println("Hey dude! I can assure you that the operand on the right side is definitely greather than or equal to 2");
} else {
System.out.println("The operand on the right side is definitely less than 2");
}
``````
###### Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Commented:
An int is 32 bits.

I assume that the code "sees" no use in shifting over the width of the var.

But I agree that 0 had beeen a better result.

;JOOP!
0

Experts Exchange Solution brought to you by

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Commented:
I overlooked the last of your post.

Anyway, the JDK does not contain the source(s) of the runtime arithmetic.
You will have to report this as a bug to SUN.

;JOOP!
0
Commented:
The second line will be printed for values

0,1,
32,33
64,65
96,97
...

(exactly as expected)
0
Commented:
(At least that's what *i* expect ;-) If you don't, tell us why not
0
Commented:
This behavior is per the JVM spec:
(for ishr instruction)  "..as if [shift value] were subjected to a bitwise logical AND with the mask value 0x1f."

Why Java implementors came to this decision, I do not know.
0
Commented:
>> "..as if [shift value] were subjected to a bitwise logical AND with the mask value 0x1f."

IOW - it wraps ;-) Don't most (all?) ops?
0
Author Commented:
THANKS
0
###### It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Java

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.