Will a long % int will always fit into an int

Can anyone confirm if this is true?

Java will turn a long % int into 开发者_如何学Goa long value. However it can never be greater than the modulus to it is always safe to cast it to an int.

long a = 
int b =
int c = (int) (a % b); // cast is always safe.

Similarly a long % short will always be safe to cast to a short.

If true, does any one know why Java has a longer type for % than needed?

Additionally, there is a similar case for long & int (if you ignore sign extension)

For most (if not all) arithmetic operations, Java will assume you want the maximum defined precision. Imagine if you did this:

long a = ...;
int b = ...;

long c = a % b + Integer.MAX_VALUE;

If Java automatically down-casted a % b to an int, then the above code would cause an int overflow rather than setting c to a perfectly reasonable long value.

This is the same reason that performing operations with a double and an int will produce a double. It's much safer to up-cast the least-accurate value to a more accurate one. Then if the programmer knows more than the compiler and wants to down-cast, he can do it explicitly.

Update

Also, after thinking more about this, I'm guessing most CPU architectures don't have operations that combine 32-bit and 64-bit values. So the 32-bit value would need to be promoted to a 64-bit value just to use it as an argument to the CPU's mod operation, and the result of that operation would be a 64-bit value natively. A down-cast to an int would add an operation, which has performance implications. Combining that fact with the idea that you might actually want to keep a long value for other operations (as I mention above), it really wouldn't make sense to force the result into an int unless the developer explicitly wants it to be one.

It is always safe! (Math agrees with me.)

The result of a mod operation is always less than the divisor. Since the result of a mod operation is essentially the remainder after performing integer division, you will never have a remainder larger than the divisor.

I suspect the reason for having the operation return a long is because the divisor gets expanded to a long before the operation takes place. This makes a long result possible. (note even though the variable is expanded in memory, its value will not change. An expanded int will never be larger than an int can hold.)

As Marc B alluded to, Java will promote b to a long before actually doing the % operation. This promotion applies to all the arithmetic operations, even << and >> I believe.

In other words, if you have a binary operation and the two arguments don't have the same type, the smaller one will be promoted so that both sides will have the same type.

This is a late party chime-in but the reason is pretty simple:

The bytecode operands do need explicit casts (L2I) and longs need 2 stack positions compared to 1 for int, char, short, byte [casting from byte to int doesn't need a bytecode instruction]. After the mod operation the result takes 2 positions on the top of stack.

edit: Also, I forgot to mention Java doesn't have division/remainder of 64b/32b. There are only 64->64bit operations, i.e. LDIV and LREM.

does any one know why Java has a longer type for % than needed?

I don't know for sure. Maybe to make it work exactly the same way as the other multiplicative operators: * and \. In the JLS The type of a multiplicative expression is the promoted type of its operands. Adding an exception to long % int would be confusing.