Boxing & Equality

Kotlin shows a single Int type, but under the hood on the JVM it lives in two forms: the primitive int (held by value, no allocation) and the wrapper object Integer (held on the heap, reached by reference). The move from the first form to the second is called boxing. It happens silently — as soon as a number lands where an object is required: in Int?, in a generic, in a collection.

The main trap surfaces at comparison. The === operator compares references, == compares content. For boxed numbers === depends on whether it is the same object, and the JVM caches small Integers, so === yields true for 1 and false for 1000. Understanding these transitions separates "learned the syntax" from "understand the runtime". The full map is in the layers below.

Topic map

• Boxing of primitives — when Int compiles to the primitive int and when to the Integer object.
• Nullable types and boxing — why Int? is always boxed and how it differs from Int.
• Reference vs structural equality — the difference between === and ==, and when boxing makes === treacherous.
• The Integer cache — why Integer for -128..127 is cached and how that changes the === result.

Common traps

Interview relevance

Boxing is asked as a check of whether you see the real JVM representation behind Kotlin's clean syntax. A candidate who says "Int is a primitive, Int? is a boxed Integer, and === compares references" immediately gets ahead of one who is sure "everything is an object in Kotlin".

Typical checks:

• When Int stays a primitive and when it is boxed.
• How Int? differs from Int at the bytecode level.
• The difference between === (reference) and == (content).
• Why === yields true for 1 but false for 1000.

Common wrong answer: "there are no primitives in Kotlin, every Int is an object". In fact the compiler represents a non-nullable Int as the primitive int; it becomes an object only when boxed — in Int?, a generic, or a collection.