Experience J2SE 1.5 new features of boxing and unboxing

J2SE 1.5 provides the "autoboxing" and "auto-unboxing" mechanisms that allow compilers to automate the transformation between the base type and their wrapped objects, thus allowing for a simpler way to avoid some of the hassle of having two sets of type systems in parallel. This paper introduces the usage, essence, timing, limitation, influence of the overload mechanism and the hindrance to the performance of autoboxing/auto-unboxing mechanism.

Traditionally, in a Java program, a container class (whether collection or map) can be placed directly into an object, but if you are going to put a number, character, or Boolean, add a step to "generate the object that wraps them."

The reason for this is that there are two very different types of systems in the Java language:

A set of so-called "reference types" (Reference Types), including all classes and interfaces. These types of data are treated as objects, so you can save them with an object-type variable.

A set of so-called "basic types" (primitive Types) includes: Byte, short, int, long, float, double, char, and Boolean. These types of data are not objects and therefore cannot be saved with object-type variables.

Using both types of systems, there are some performance benefits--because the underlying type of data is not an object, so it's easier to create faster, take less space, and reclaim the resources they occupy, but it can also cause some coding problems--for example, Cannot define a variable (or array). Let it save both the basic type of data and the data of the reference type (similarly, you can't define a formal parameter that matches both types of data, but this problem can be circumvented by the overload mechanism in Java).

When you actually need to define variables (and formal parameters that don't know what type of data to hold), you generally take a evasive approach to the problem, define their types as object, and then use what can be called "Boxing" and "unboxing" Action to resolve an object that does not cover a basic type of problem.

1. Boxing and unboxing operations

The so-called boxing operation refers to the creation of an object that can wrap the basic type of data so that the basic type of data can be found in only the reference type.

Listing 1: Typical cases of manual boxing

Collection integers = new ArrayList();
for(int i = 0; i < 10; i++) {
integers.add(new Integer(i));
}

The class that is used to generate these objects is called the "Parcel Class" (wrapper Classes). The package classes in Java include Byte, short, Integer, long, Float, Double, character, and Boolean (all defined in the Java.lang package), respectively, for wrapping byte, short, int, long , float, double, char, and Boolean types of data.

The so-called unboxing operation refers to the corresponding method of calling the parcel object, and obtains the "basic type of data" which they represent for further disposal.

Listing 2: Typical cases of manual unboxing

for(Iterator itr = integers.iterator(); itr.hasNext(); ) {
Integer i = (Integer) itr.next();
System.out.println(i.intValue() + 1);
}

In the latest version of the Java language,--J2SE 1.5, the "autoboxing" and "auto-unboxing" mechanisms are available to allow compilers to automate these trivial operations, thus consolidating two sets of type systems in a simpler way.

A familiar unfamiliar noun

Although this pair of operations has a long history, the practice of calling them "Boxing" and "unboxing" is generally accepted only after the concept of "autoboxing" and "auto-unboxing" have emerged. Until then, they did not seem to have a generic, specialized name. But since the two concepts were rarely mentioned at the time, the problem did not have a serious impact.