Jeremy's code might look better. But it uses %. which is far worse then dividing on really low level
Not that you will notice it. But sometimes short code isnt always the best
Sorry I didn't consider the code at such an absurdly irrelevant microscopic level. Your argument is based severely on two things:
A ) Optimizations for particular architectures
B ) The underlying implementation on a OPCODE level
Which means unless your profiler makes a point about it, it means nothing in Java which has no concept of either.
I'm sure this will work fine for anyone, and if it doesn't they shouldn't consider hacking into bit-shifting operators unless their profiler tells them they have to.
Finally, this won't be used for large numbers as was illustrated by the OP.
My solution was general for all integers, not specifically for an RGB colour - however I am sure if you remove that abstraction you will get some better optimizations.