Boxing Conversions

Before reading this, go read TypeErasure. Are you done? Ok.

A boxing conversion is the conversion of an object between a form which has type information available for the runtime system, and a form which does not (in other words, the latter has been subject to TypeErasure). The addition of the runtime information is called boxing (think of putting something into a box with a label identifying the contents); the opposite is called unboxing. Sometimes you will see the term "auto boxing"--which is essentially the same thing (though transparent to the programmer). Programmers in pre-1.5 JavaLanguage are familiar with manual boxing--essentially, conversion between intrinsic types like "int" and the associated Object forms like java.lang.Integer is manual boxing/unboxing (the intrinsic form is the unboxed version, the Object is the boxed version). In Java 1.5, the compiler will do this for you automagically; CsharpLanguage does this as well. (In Java 1.5, one still has the dichotomy between int and Integer; in C# it all happens under the hood).

Why are boxing conversions (in particular, automatic ones) useful? Dealing with "small" objects like ints and bools has long been a problem for OO languages--do we make these full-fledged Objects or not? If yes, then they can't be subject to TypeErasure and thus incur a lot of overhead. SmalltalkLanguage does this. If no, then we can perform TypeErasure but the conceptual integrity of the language suffers (this is a major headache with Java). BoxingConversions give us the best of both worlds--ideally.

A boxing conversion works like this: If an int (or similar object) is declared, it is allocated to a register and subject to TypeErasure--just like an int in a non-OO language like CeeLanguage. If and when the int gets passed to a context where other objects (non-ints) are valid, at that point the boxed version (a full-fledged object) is allocated, containing a copy of the int. Conversely, if such an object is downcast to an int (or otherwise used in a context where it is known that the type is int and nothing else), then the compiler can extract the int out of the object; throw away the object reference (leading to GarbageCollection if it is no longer valid), and once again stuff it in a register.

Note that boxing conversions (in both directions) involve making a copy. Compilers don't dynamically resize objects, adding/deleting the pointer to the type information as appropriate.

One generally only does this with objects that are a) small, b) immutable, and c) final (incapable of being further subtyped, though type restrictions/subranges might be OK). It isn't worth the hassle for large objects (and the copying would get expensive); objects which might be further subtyped are not candidates for TypeErasure, and objects with mutable state don't have the property that copying and aliasing are semantically equivalent (necessary, as the copying should be semantically neutral). Were mutable objects to be subject to BoxingConversions, it would be necessary to ensure that a state change on one is propagated to all; you don't want to go there.

But JavaAutoboxingIsNot.

This description is very Java-centric. Autoboxing is the automatic moving of a variable's value directly within a variable to storage that is referred indirectly through a reference stored in the variable. Some languages do this without using dynamic type information at all.

Strictly Java does not do autoboxing. It does type coercion. As the paragraph above says, autoboxing is purely about moving a value between storage locations. True autoboxing does not change the value's type. Java, on the other hand, actually coerces int values to java.lang.Integer values and back (and likewise for other autoconversions).