Actually, they all make sense. It's plain 2's complement binary
arithmatic.
First of all, 0xF0F0F0F0 is a negative (signed) integer number. So
assigning it to a long makes it 0xFFFFFFFFF0F0F0F0L.
This accounts for the fact that all 1's are shifted in when you shift
right, even if you use '>>>'.
Secondly, 1 << 31 = 0x80000000, which is a negative number. Making it long
converts it to 0xFFFFFFFF80000000L. So (l&i) does not extract bit 31, but
bits 63 throug 31.
For the last line, this makes 0xFFFFFFFF0F0F0FL & 0xFFFFFFFF80000000 =
0xFFFFFFFF00000000. This is different from 0, so a "1" gets printed.
I would advise you to make sure you use only longs for this arithmetic.
(Append a 'L' to the constants). Automatic conversions from integers to
longs can produce confusing results as you have noticed.
BTW, why don't you use Long.toBinaryString() ?
Cheers,
Dirk.
