Editing Boxing (computer programming) (section)

==Autoboxing==
Autoboxing is the term for getting a reference type out of a value type just through [[type conversion]] (either implicit or explicit). The compiler automatically supplies the extra source code that creates the object.

For example, in versions of Java prior to J2SE 5.0, the following code did not compile:

<syntaxhighlight lang=Java>
Integer i = new Integer(9);
Integer i = 9; // error in versions prior to 5.0!
</syntaxhighlight>

Compilers prior to 5.0 would not accept the last line. {{Java|Integer}} are reference objects, on the surface no different from {{Java|List}}, {{Java|Object}}, and so forth. To convert from an {{Java|int}} to an {{Java|Integer}}, one had to "manually" instantiate the Integer object. As of J2SE 5.0, the compiler will accept the last line, and automatically transform it so that an Integer object is created to store the value {{Java|9}}.<ref>[https://docs.oracle.com/javase/1.5.0/docs/guide/language/autoboxing.html oracle.com Java language guide entry on autoboxing]</ref> This means that, from J2SE 5.0 on, something like {{Java|1=Integer c = a + b}}, where {{Java|a}} and {{Java|b}} are {{Java|Integer}} themselves, will compile now — a and b are unboxed, the integer values summed up, and the result is autoboxed into a new {{Java|Integer}}, which is finally stored inside variable {{Java|c}}. The equality operators cannot be used this way, because the equality operators are already defined for reference types, for equality of the references; to test for equality of the value in a boxed type, one must still manually unbox them and compare the primitives, or use the {{Java|Objects.equals}} method.

Another example: J2SE 5.0 allows the programmer to treat a collection (such as a {{Java|LinkedList}}) as if it contained {{Java|int}} values instead of {{Java|Integer}} objects. This does not contradict what was said above: the collection still only contains references to dynamic objects, and it cannot list primitive types. It cannot be a {{Java|LinkedList<int>}}, but it must be a {{Java|LinkedList<Integer>}} instead. However, the compiler automatically transforms the code so that the list will "silently" receive objects, while the source code only mentions primitive values. For example, the programmer can now write {{Java|list.add(3)}} and think as if the {{Java|int}} {{Java|3}} were added to the list; but, the compiler will have actually transformed the line into {{Java|list.add(new Integer(3))}}.

===Automatic unboxing===
With automatic unboxing the compiler automatically supplies the extra source code that retrieves the value out of that object, either by invoking some method on that object, or by other means.

For example, in versions of Java prior to J2SE 5.0, the following code did not compile:

<syntaxhighlight lang=Java>
Integer k = new Integer(4);
int l = k.intValue(); // always okay
int m = k;            // would have been an error, but okay now
</syntaxhighlight>

C# doesn't support automatic unboxing in the same meaning as Java, because it doesn't have a separate set of primitive types and object types. All types that have both primitive and object version in Java, are automatically implemented by the C# compiler as either primitive (value) types or object (reference) types.

In both languages, automatic boxing does not downcast automatically, i.e. the following code won't compile:

C#:
<syntaxhighlight lang="csharp">
int i = 42;
object o = i;         // box
int j = o;            // unbox (error)
Console.WriteLine(j); // unreachable line, author might have expected output "42"
</syntaxhighlight>

Java:
<syntaxhighlight lang="java">
int i = 42;
Object o = i;          // box
int j = o;             // unbox (error)
System.out.println(j); // unreachable line, author might have expected output "42"
</syntaxhighlight>