4.1 Converting Primitives to Wrapper Types
Integer i = 0;Behind the scenes, primitive values are boxed. Boxing refers to the conversion from a primitive to its corresponding wrapper type: Boolean, Byte, Short, Character, Integer, Long, Float, or Double. Because this happens automatically, it's generally referred to as autoboxing.
It's also common for Java to perform a widening conversion in addition to boxing a value:
Number n = 0.0f;Here, the literal is boxed into a Float, and then widened into a Number.
Additionally, the Java specification indicates that certain primitives are always to be boxed into the same immutable wrapper objects. These objects are then cached and reused, with the expectation that these are commonly used objects. These special values are the boolean values true and false, all byte values, short and int values between -128 and 127, and any char in the range \u0000 to \u007F.
4.2 Coverting Wrapper Types to Primitives
// Boxingint foo = 0;Integer integer = foo;// Simple Unboxingint bar = integer;Integer counter = 1; // boxingint counter2 = counter; // unboxing...null value assignment? Since null is a legal value for an object, and therefore any wrapper type, the following code is legal:
Integer i = null;int j = i; i is assigned null (which is legal), and then i is unboxed into j. However, null isn't a legal value for a primitive, so this code throws a NullPointerException.
4.3 Incrementing and Decrementing Wrapper Types
Suddenly, every operation available to a primitive should be available to its wrapper-type counterpart, and vice versa.
Integer counter = 1;
while (true) 
{
System.out.printf("Iteration %d%n", counter++); if (counter > 1000) break;
}Remember that counter is an Integer. So the value in counter was first auto-unboxed into an int, as that's the type required for the ++ operator. Once the value is unboxed, it is incremented. Then, the new value has to be stored back in counter, which requires a boxing operation. All this in a fraction of a second!
4.4 Boolean Versus boolean
Any time you have an expression that uses !, ||, or &&, any Boolean values are unboxed to boolean primitive values, and evaluated accordingly:
Boolean case1 = true; Boolean case2 = true; boolean case3 = false; Boolean result = (case1 || case2) && case3;For inquiring minds, primitives are boxed up to wrapper types in equality comparisons. For operators such as <, >=, and so forth, the wrapper types are unboxed to primitive types.
Atten! ...direct object comparison?
You can't depend on the result; it's merely used as an illustration. Some JVMs may choose to try and optimize this code, and create one instance for both Integer objects, and in that case, the == operator would return a true result.
Integer i1 = 256; Integer i2 = 256; Integer i3 = 100; Integer i4 = 100; System.out.println(i1 == i2); // false System.out.println(i3 == i4); // trueIf you wonder the result above, check the last paragraph in 4.1 Converting Primitives to Wrapper Types.
4.5 Conditionals and Unboxing
Ternary operator --- [conditional expression] ? [expression1] : [expression2]
[expression1] and [expression2] had to either be of the same type, or one had to be assignable to the other.
Another addition to Tiger is automatic casting of reference to their intersection type. That's a mouthful, so here's an example:
String s = "hello"; StringBuffer sb = new StringBuffer("world"); boolean mutable = true; CharSequence cs = mutable ? sb : s;In pre-Tiger environments, this would generate an error, as sb (a StringBuffer) and s (a String) cannot be assigned to each other, unless you explicitly cast both to CharSequence.
As a side effect of this, note that two reference types (objects) always share java.lang.Object as a common ancestor, so any result of a ternary operation involving non-primitive operands can be assigned to java.lang.Object.
4.6 Control Statements and Unboxing
if/else, while, and do all are affected by Tiger's ability to unbox Boolean values to boolean values.
Another statement that benefits from unboxing is switch. In pre-Tiger JVMs, the switch statement accepts int, short, char, or byte values. With unboxing in play, you can now supply it with Integer, Short, Char, and Byte values as well, in addition to the introduction of enums.
4.7 Method Overload Resolution
In Tiger, method resolution is a three-pass process:
-
The compiler attempts to locate the correct method without any boxing, unboxing, or vararg invocations. This will find any method that would have been invoked under Java 1.4 rules.
-
If the first pass fails, the compiler tries method resolution again, this time allowing boxing and unboxing conversions. Methods with varargs are not considered in this pass.
-
If the second pass fails, the compiler tries method resolution one last time, allowing boxing and unboxing, and also considers vararg methods.
These rules ensure that consistency with pre-Tiger environments is maintained.