What Is Type Casting in Java? Widening vs Narrowing

A widening conversion moves a value into a type that can hold every value of the original type, so no information is lost. The compiler performs these implicitly: byte to short to int to long to float to double, plus char to int and above, and int to float or double. Widening is always safe, which is exactly why the language allows it without a cast — and why a long assigned to an int requires an explicit cast, since the int cannot hold every long.

A narrowing conversion goes the other way and can lose information, so it requires an explicit cast. Narrowing from a floating-point type to an integer truncates toward zero, dropping the fractional part. Narrowing from a wider integer to a narrower one discards the high bits, keeping only the low-order bits, which is modulo arithmetic rather than saturation.

public class Main {
    public static void main(String[] args) {
        int small = 42;
        long wide = small;         // widening: implicit and always safe
        double precise = small;   // widening: int -> double
        System.out.println("int -> long   : " + wide);
        System.out.println("int -> double : " + precise);

        double notWhole = 9.99;
        int truncated = (int) notWhole;   // narrowing: fraction dropped
        System.out.println("9.99 -> int   : " + truncated);

        char letter = 'A';
        int code = letter;               // widening: char -> int
        System.out.println("'A' -> int    : " + code);

        int overflow = 300;
        byte narrowed = (byte) overflow; // keeps the low 8 bits -> 44
        System.out.println("300 -> byte   : " + narrowed);
    }
}

The last line is the one to dwell on. Casting 300 to a byte does not clamp to 127; it keeps the low eight bits, so the result is 44. That is the same behaviour as integer overflow, and it is why a careless narrowing cast in a protocol parser can turn a length field into a small, plausible-looking number. Wherever a narrowing cast might actually lose data, prefer a method that either validates the range for you or throws instead of silently truncating.

A plain cast does not fail; it truncates. Casting a long of four billion to an int keeps the low 32 bits, which for that particular value happens to produce a negative number rather than the original. Nothing is thrown, nothing is logged, and the bug surfaces much later as an inexplicable negative count.

There are three better options, and choosing between them is exactly the kind of judgement an interviewer likes to hear about. Math.toIntExact throws an ArithmeticException if the value does not fit, which is the right default when an out-of-range value is a bug you want to know about immediately. Math.toIntExact is not the only such helper: Long.toIntExact and Double.toIntExact both exist, and Math.round returns a long with the fraction rounded rather than truncated. If instead an out-of-range value should be clamped to the nearest legal value, use Math.min and Math.max to do it by hand.

public class Main {
    public static void main(String[] args) {
        long big = 4_000_000_000L;

        int viaCast = (int) big;   // silently truncates
        System.out.println("plain cast    : " + viaCast);

        int guarded = (big >= Integer.MIN_VALUE && big <= Integer.MAX_VALUE)
                ? (int) big
                : -1;
        System.out.println("range check   : " + guarded);

        try {
            int strict = Math.toIntExact(big);
            System.out.println("toIntExact    : " + strict);
        } catch (ArithmeticException e) {
            System.out.println("toIntExact    : threw ArithmeticException instead of truncating");
        }

        double d = 3.99;
        System.out.println("Math.round    : " + Math.round(d));
        System.out.println("(int) cast    : " + (int) d);
    }
}

Two related notes. First, the truncation rule for a floating-point to integer cast is toward zero, so a negative value loses differently from a positive one: casting -3.99 gives -3, not -4, while Math.round(-3.99) gives -4. Second, widening an int to a double is always safe in terms of magnitude but can lose precision, because a double cannot represent every 32-bit integer exactly above 2 to the 53rd power — for practical int values it is fine, and for long values it is not, which is another reason long to double needs care in financial code.

The rule exists because narrowing is not guaranteed to be lossy in the value you have — it is only potentially lossy in general. Casting a long of 42 to an int loses nothing, so requiring a cast for that case would be noise. But the compiler cannot see your data, so it cannot know whether the particular value fits. Making the conversion explicit forces you to state that you have considered it, which puts the decision where the knowledge lives.

Where it goes wrong in practice is money. Suppose a price is held as a double, and the code casts it to an int cents amount. The double 19.99 is not exactly 19.99 in binary floating point — it is very slightly less — so multiplying by 100 and truncating gives 1998 instead of 1999. A single cent disappears per conversion, and it disappears silently. The fix is to never represent money as a double at all: use BigDecimal with an explicit scale and rounding mode, or store integer minor units such as cents and format them only at the edge.

The second classic is a length field. A protocol gives you a payload length as a long, and you cast it to an int to index an array. A malformed or hostile length of four billion truncates to a small integer, the bounds check passes, and the code reads the wrong data. The three defences are to check the range before casting, to use Math.toIntExact so the cast fails loudly, and to validate the value against the actual remaining buffer length regardless of how it was converted.

One more subtlety worth raising: the arithmetic operators promote byte and short to int before computing, so a byte arithmetic expression is really an int expression that gets narrowed back on assignment. That is why b += 1 wraps silently at 127 while b = b + 1 does not compile without a cast.