Type Conversion & Casting

When you do arithmetic on two numbers, Java converts both to a common type before computing. Anything smaller than int (byte, short, char) becomes int first. So byte + short gives an int.

Widening turns a smaller numeric type into a bigger one, like int to long or int to double. Java does it automatically because the bigger type can always hold the value, so no data is lost.

Upcasting treats an object as one of its parent types and happens automatically. Downcasting treats it as a more specific child type and must be written explicitly with a cast like (Dog) animal.

Wrapper classes like Integer, Long, Double, Boolean, and Character are object versions of the eight primitive types. They exist because generics and collections only hold objects, not primitives, and they add helper methods and constants.

A wrapper like Integer can be null. When you use it where a primitive is needed, the compiler inserts an unboxing call (intValue()) on that null, which throws a NullPointerException. Check for null, or use a primitive default.

Because both operands are promoted to a common type, an int/int division stays integer (truncates), and an int times int can overflow before being assigned to a long. Cast one operand to long or double first to fix it.

Narrowing converts a bigger type into a smaller one, like double to int or int to byte. Java does not do it automatically because the value might not fit, so you must write a cast like (int)x, and you can lose data.

It is a runtime error thrown when you cast an object reference to a type the object actually isn't. Prevent it by checking the type first with instanceof before casting.

Integer.valueOf caches the small values -128..127, so autoboxing 127 twice returns the same object and == is true. 128 is outside the cache, so two new objects are created and == compares references, giving false. Always use .equals for wrappers.

In arithmetic, a char is treated as its numeric Unicode code value and promoted to int. 'a' has code 97, so 'a' + 1 evaluates to the int 98, not the character 'b'.

== on two Integer objects compares references, not values. Java caches small boxed Integers (-128 to 127), so two boxes of the same small value share one object and == is true; outside that range you get distinct objects and == is false. Use .equals() or compare as int.

Unary numeric promotion converts a single operand. If it is smaller than int (byte, short, char), it becomes int; otherwise it keeps its type. It applies to things like unary minus, the array index, bit shifts, and ~.

Java keeps only the low bits that fit the smaller type and throws the rest away. (byte) 257 is 1 because 257 is 256+1 and only the low 8 bits survive. (short) 70000 is 4464 for the same reason with 16 bits.

parseInt returns a primitive int; valueOf returns an Integer object (possibly from the cache). Both can take a radix (e.g. base 16) and both throw NumberFormatException on bad input. Use parseInt when you want an int, valueOf when you need the wrapper.

Each autobox creates (or fetches) a wrapper object and each unbox is a method call. In loops or large sums this means many heap allocations, more garbage collection, and cache-unfriendly pointer chasing. Use primitives, primitive arrays, and primitive streams (IntStream) instead of wrappers.

When picking an overloaded method, Java first tries widening primitives (like numeric promotion), then boxing, then varargs — in that order. So for a short argument it prefers a method taking int (widening) over one taking Integer (boxing).

In math expressions Java automatically widens small types to at least int before computing. So byte + byte gives an int, and mixing an int with a double makes the whole thing a double. This is why byte b = b1 + b2; needs a cast.

The compiler rejects a cast only when the types could never be related, so it can never succeed. If the types are on the same inheritance line, the cast is possible, so the compiler allows it and lets the JVM check at runtime.

Integer.compare(a, b) never overflows, but the old trick a - b can overflow when the difference exceeds int range and then return the wrong sign. Similarly Math.abs(Integer.MIN_VALUE) overflows and stays negative, because MIN_VALUE has no positive counterpart.

Avoid letting numbers silently shrink or lose digits. Use long instead of int where overflow is possible, BigDecimal for exact money math, and helpers like Math.toIntExact that throw on overflow. Pick API parameter types that don't force lossy conversions on callers.

Generic type info is erased at runtime, so unsafe code can put the wrong type into a collection. The error then appears later, at the hidden cast the compiler adds when you read the element, not where the bad value went in.

Avoid boxing in hot paths by using primitives, primitive streams, and primitive-specialized collections; never rely on the integer cache (==) for correctness because its range can differ by JVM config. Enforce these with static analysis and benchmarks rather than intuition.