Java final, primitives, and boxing.

Variables showed that assignment copies whatever a variable holds: a primitive value or a reference. Java has exactly eight primitive types: byte, short, int, and long for whole numbers, float and double for decimals, char for one character, and boolean. Every other type, including String and every array, is a reference type.

Each primitive type has a wrapper class, whose objects each hold one value of that type. Integer wraps int; the others are Byte, Short, Long, Float, Double, Character, and Boolean. A collection holds objects, never primitives. The type in angle brackets says what a collection holds, so a list of whole numbers is a List<Integer>, never a List<int>.

Java converts between int and Integer for you. The conversion from int to Integer is called boxing, and the conversion back is unboxing. javac compiles boxing as a call to Integer.valueOf, which returns an Integer object that holds the number, and unboxing as a call to intValue on the object. Both calls are in the compiled program; they do not appear in your code.

An Integer object never changes. boxed = boxed + 1 unboxes boxed, adds 1, and boxes the result into a different Integer. A variable that still refers to the first object still sees the old number.

int holds a number; Integer holds a reference to an object, and javac converts between them with method calls you do not write.

== asks a different question for each kind of value. For two primitives, == compares the values: 128 == 128 is true. For two references, == is true when both lead to the same object. So for two Integer objects, == compares objects, not numbers.

The trap is that small numbers seem to work. Integer.valueOf keeps one Integer object for each number from -128 to 127, and returns that same object every time. The Java Language Specification requires this range. Two boxed 127s are therefore one object, and == says true. Two boxed 128s are two objects unless Java was started with a larger cache (the note below shows how), and == says false. A test with small numbers passes, and the same code fails with larger ones.

To compare the numbers, use equals: large.equals(largeAgain) is true when both hold the same number. When one side of == is an int, Java unboxes the other side and compares numbers, so an int compared with an Integer is safe unless the Integer is null.

Compare Integer objects with equals; == on two Integers compares objects.

An Integer variable can hold null, because it holds a reference. An int cannot. When Java must unbox null, the hidden intValue call has no object to run on, and the program throws a NullPointerException: an exception, an object that stops the normal flow of the program when an operation fails.

The most common source is a map: on a Map<String, Integer>, get returns null for a key the map does not contain. Assigning that result to an int unboxes it at once, and Java 17 says what was null:

Cannot invoke "java.lang.Integer.intValue()" because the return value of "java.util.Map.get(Object)" is null

The message names intValue, a method your code never calls. That name is the sign of unboxing.

There are two fixes. getOrDefault(key, 0) returns 0 for a missing key, which is right when a missing entry means none. Keeping the result in an Integer and testing it against null lets the code treat a missing entry differently from an entry of 0.

The same choice comes back when you write a method that sometimes has no number to return. An int with a special value, such as -1, works when -1 can never be a real answer. An Integer can be null, and every caller must test it before unboxing. OptionalInt, from java.util, is an object that holds one int or nothing, and the caller must ask which before using the number.

Unboxing null throws NullPointerException; test for null or use a default before a value becomes an int.

A class can have several methods with the same name and different parameter types. Each one is an overload, and the compiler chooses one from the types of the arguments. List has two remove methods. remove(int index) removes the element at a position, counting from 0. remove(Object o) removes the first element equal to o.

For a List<Integer>, rooms.remove(2) could mean either one. The compiler first looks for a method that fits without boxing. remove(int) fits, so the call removes the element at index 2. To remove the value 2, pass an object: rooms.remove(Integer.valueOf(2)). The choice depends on the declared type of the argument, so a variable declared Integer also selects remove(Object).

In the code below, List.of(5, 2, 9) makes a list that cannot change, and new ArrayList<>(...) copies it into a list that can.

On a List<Integer>, remove(2) removes a position; remove(Integer.valueOf(2)) removes a value.

final can be written on three kinds of variable, and for each one it stops a second assignment. It does not stop the object that the variable refers to from changing; the experiment below changes a field of an object through a final variable.

A final local can be assigned once, in its declaration or on a later line. javac rejects a second assignment and points at that line. After final int limit = 3;, the line limit = 4; gives:

error: cannot assign a value to final variable limit

If the declaration has no value and two later lines assign limit, the second one gives: error: variable limit might already have been assigned.

A final parameter receives its value from the call, so any assignment in the method is rejected:

error: final parameter n may not be assigned

A final field must be assigned exactly once. A final instance field (one copy per object) can be assigned in its declaration, in an instance initializer block (a { } block written directly in the class body, which runs for every new object), or in a constructor. Whichever place is used, the field must be assigned exactly once by the end of every constructor. A static final field (one copy for the class) is assigned in its declaration or in a static initializer block, static { }. If a constructor can finish without assigning the field, javac points at the closing brace of that constructor:

error: variable litres might not have been initialized

For a class with no constructor of its own, the message is: error: variable litres not initialized in the default constructor. An assignment to the field in any other method gives the “cannot assign a value to final variable” error.

final on an Integer variable stops reassignment, and the Integer object could never change anyway. Integer keeps its number in a field declared private final int value, the field the stepper shows as {value: 7}. A class whose fields are all final, and hold primitives or objects that cannot change, makes objects that cannot change. Integer and String are built this way.

final stops a second assignment to a local, a parameter, or a field; it never makes the object unchangeable.

Each bug below follows from a rule in this lesson, and each one can pass every test with small data.

Database ids are often Long objects, and Long.valueOf shares objects only from -128 to 127, as Integer.valueOf does. So order.ownerId() == user.id() is true for the first 127 users and false after that. Compare ids with equals, or with Objects.equals(a, b) from java.util when either id can be null.

A Set<Long> never contains an int. ids.contains(5) boxes 5 to an Integer, and an Integer is never equal to a Long, so the result is false even when the set holds 5L. On a Map<Long, String>, owners.get(42) returns null for the same reason. Both calls compile, because contains and get accept any Object. Write 5L, or pass a long variable.

A counter map crashes on the first occurrence of each key: counts.put(colour, counts.get(colour) + 1) unboxes null for a colour not yet in the map. counts.merge(colour, 1, Integer::sum) stores 1 for a new key. For a key that is already there, merge calls the function given as its third argument with the old count and 1, and stores the result. Integer::sum is a method reference: it passes the existing method Integer.sum, which adds two ints, as that function. The lambda (old, one) -> old + one, a small function written in place, would do the same.

A final field that holds a list does not stop the list from changing. If a constructor stores the list it receives, the object shares that list with the code that called the constructor, and a later change to the list appears in the object. Store List.copyOf(list), a copy that cannot be changed. Collections.unmodifiableList(list) is not a copy: it refuses changes made through it, but it shows changes made to the original list.

Compare Long ids with equals, pass a long to a Long collection, count with merge, and copy a list before a final field stores it.

Each comparison below compares either two objects or two numbers. Decide which before predicting the output.