Tricky Output Questions

01Rule 1: boxing, the cache and the conditional operator

Integer a = 127 compiles to Integer.valueOf(127). The Java Language Specification requires valueOf to return cached objects for -128 to 127, so two boxes of 127 are the same object and == is true. 128 is outside the cache, so each valueOf(128) creates a new object and == compares two different references: false. (The upper bound can be raised with -XX:AutoBoxCacheMax, which is why you must never rely on it.)

== between a box and a primitive unboxes, so Long big = 127L; big == 127 is a numeric comparison: true. But big.equals(127) boxes 127 to an **Integer**, and Long.equals returns false for anything that isn't a Long.

The conditional operator ?: has its own typing rules. If one operand is int and the other double, the result is double, so true ? 1 : 2.0 is 1.0. If one operand is Integer and the other int, the result type is int, so a null Integer operand is unboxed and throws NullPointerException, even when you assign the result back to an Integer.

Integer none = null;
Integer r = flag ? none : 0;   // type of ?: is int: none.intValue() throws NPE
Integer s = flag ? none : Integer.valueOf(0);   // both Integer: no unboxing, s = null

02Rule 2: List.remove and the Short set

List<Integer> has two remove methods: remove(int index) and remove(Object o). list.remove(1) matches remove(int) exactly, so it removes the element at index 1. Overload resolution tries methods without boxing first (Rule 5), so you must write list.remove(Integer.valueOf(1)) to remove the value 1.

In Set<Short> s; s.remove(i - 1) with short i, the expression i - 1 is an **int** (promotion), which boxes to Integer. remove(Object) accepts it, finds no equal Short (an Integer never equals a Short), and removes nothing. The compiler can't help, because Collection.remove takes Object.

03Rule 3: Strings are built left to right; chars are numbers

+ is left-associative. "x" + 1 + 2 is ("x" + 1) + 2 = "x1" + 2 = "x12". 1 + 2 + "x" is (1 + 2) + "x" = "3x". Once a String appears, every following + is concatenation.

A char is an unsigned 16-bit number. In arithmetic, char is promoted to int, so 'a' + 'b' is 97 + 98 = 195, and 'a' + 2 is 99. Cast back with (char) to get a character. Compound assignment c += 1 includes a hidden cast, so it compiles on a char, while c = c + 1 doesn't ("incompatible types: possible lossy conversion from int to char").

Strings are immutable: s.toUpperCase() returns a new String, and if you ignore the result, s is unchanged. Concatenating null produces the text "null". StringBuilder does not override equals, so two builders with the same text are not equals; use contentEquals or compare toString().

char x = 'x';
int i = 0;
System.out.println(true ? x : 0);   // x   : 0 is a constant that fits in char, so the type is char
System.out.println(true ? x : i);   // 120 : i is an int variable, so the type is int

04Rule 4: increments, division and overflow

Java evaluates operands left to right, and each i++ or ++i takes effect immediately. With i = 5, i++ + ++i is: left operand i++ yields 5 and sets i to 6; right operand ++i sets i to 7 and yields 7; sum 12, i ends at 7. j = j++ yields the old value 5, increments j to 6, then the assignment stores 5 back: j stays 5.

Integer / truncates toward zero (-7 / 2 is -3), and % has the sign of the dividend (-7 % 3 is -1); Math.floorMod(-7, 3) gives the mathematical 2. 24 * 60 * 60 * 1000 * 1000 is computed entirely in int and overflows *before* it is widened to long; write 24L * … so the first multiplication is already long. Math.abs(Integer.MIN_VALUE) is still negative, because +2147483648 doesn't fit in an int.

05Rule 5: floating point, NaN and negative zero

0.1 and 0.2 have no exact binary representation; their sum is the nearest double to 0.30000000000000004, which is not the nearest double to 0.3, so == is false. Compare with a tolerance, or use BigDecimal for money (Topic 1.4).

IEEE 754 defines 1.0 / 0 as Infinity and 0.0 / 0 as NaN; only integer division by zero throws ArithmeticException. NaN == NaN is false; test with Double.isNaN. 0.0 == -0.0 is true, but Double.equals compares bit patterns, so Double.valueOf(0.0).equals(-0.0) is false while Double.valueOf(NaN).equals(NaN) is true: equals must be reflexive for collections to work.

Math.round(x) is floor(x + 0.5), so Math.round(-2.5) is -2, not -3. Casting a double to int truncates toward zero, and (int) NaN is 0. (byte) 200 keeps the low 8 bits, which read as -56 in two's complement.

06Rule 6: overloads at compile time, overrides at run time

The compiler resolves overloads in three phases (JLS 15.12.2): first without boxing or varargs (identity and widening only), then with boxing, then with varargs. The first phase that finds a match wins, and within it the most specific method is chosen. So n(5) prefers n(long) (widening) over n(Integer) (boxing) over n(int...). m(null) with m(Object) and m(String) picks String, the more specific type.

Overload choice uses the declared type: Object s = "text"; m(s) calls m(Object). Overriding uses the object's class: Animal a = new Dog(); a.sound() runs Dog.sound. Fields and static methods are not polymorphic: a.name reads Animal.name, and a.kind() calls Animal.kind().

07Rule 7: initialisation order

When a class is first used, its static initialisers run once, top to bottom, parent class first. Each new then runs, for each class from Object downward: field initialisers and instance blocks in source order, then the constructor body. A child's fields are therefore still at their default values (null, 0, false) while the parent constructor runs.

If a parent constructor calls an overridable method, the child's override runs early and sees those defaults. Static fields have the same trap: static final Tally ONE = new Tally(); static int created = 0; runs the constructor (created becomes 1), then the next line resets created to 0.

08Rule 8: finally runs last and can override

return x; inside try first evaluates x and saves the value, then runs finally, then returns the saved value. Changing a primitive local in finally doesn't affect what is returned; mutating an object the saved reference points to does show.

If finally itself executes return (or throw), it replaces whatever the try was doing: an earlier return value is discarded, and a pending exception is silently thrown away. javac warns with -Xlint:finally ("finally clause cannot complete normally"), and every style guide forbids it.