Its faster to compare to 0 because the JVM has opcodes specifically for that.  Comparing to a constant value like 0x40000000 requires using additional instructions to load that large integer from the constant pool onto the stack, and then compare to that integer.

When you turn around and JIT this bytecode, most processors can perform a compare-to-zero-and-conditional-jump pretty efficiently, its a very common idiom.  Comparing to a larger value like 0x40000000 still requires pushing that value into a register from the instruction stream, then doing the compare.  So assuming everything JITs out nicely, comparing to 0 should still be a full clock cycle faster than not.

Of course in all of this I'm assuming the compiler isn't smart enough to realize that the mask involved in the preceding & operator contains only a single bit set, and that therefore the result of the & operation is either going to be 0 or != 0, and that therefore it can optimize out the equality test to be a compare with zero instead of compare with the constant.  It may be that the compiler and-or-JIT is smart enough to figure that out, in which case my rule is pointless.  (FWIW, I just checked, the Sun javac can't do this optimization even when compiling with -O.)

Anyway, even ignoring all of that, our coding style when comparing a single bit is to use != 0, not the constant itself a second time.  We only use the constant when the & mask contains more than one bit and we need to test that a specific bit pattern remains, e.g. the way we test in FileMode.

:-)