1. Syntactic sugar
To talk about syntactic sugar, we must first know the meaning of syntactic sugar. Let's look at the definition in Baidu Encyclopedia, syntactic sugar (Syntactic sugar), also translated as sugar-coated grammar,
is a term coined by British computer scientist Peter J. Landin to refer to a certain grammar added to a computer language,
This syntax has no effect on the functionality of the language, but is more convenient for programmers to use. Generally speaking, the use of syntactic sugar can increase the readability of the program, thereby reducing the chance of error in the program code.
After JDK1.5, a lot of syntactic sugar has been added, such as generics, variable-length parameters, automatic boxing/unboxing, and traversal loops (foreach).
Today, let's talk about the stalk of automatic boxing and unboxing, one of the syntactic sugars.
2. One of the syntactic sugars -- automatic boxing/unboxing
In the Java language, autoboxing (autoBoxing) refers to the basic data types (byte, short, char, int, long, float, double, boolean)
Converted to the corresponding encapsulation class (Byte, Short, Character, Integer, Long, Float, Double, Boolean), the unboxing process is to
The process of restoring the corresponding encapsulated class object to the basic data type is one of our commonly used syntactic sugars.
Today we will explain some common mistakes in autoboxing/unboxing in the form of bytecode in java.
Example 1:
Integer a = 1;
Integer b = 1;
So, what does printing a==b return?
We analyze autoboxing in the form of bytecode + source code.
First, the autoboxing process for Integer a = 1 happens during the compiler compiling ".java" code into ".class".
In the bytecode, we can clearly see that the automatic boxing process uses the static method valueOf(int i) in the Integer class. Its parameter is an int value and the return type is an Integer object. See Figure.
Let's go to the Integer class to find the method and see how it is done in the source code. See Figure.
In the source code, we can see that Integer caches Integer objects between -128 and 127 in the static constant array cache[] of the private static inner class IntegerCache. If it exceeds this range, you need to create a new Integer object.
That is to say, the values in the range of -128~127, after being automatically boxed into the packaging class Integer, point to the same content.
We know that the local variables in the method are placed in the local variable table of the Java virtual machine stack frame, and the constants are placed in the method area. Therefore, at this time, the reference types a and b in the local variable table point to The cache[1+128] location in the method area. Therefore, we can clearly conclude that a==b prints out true.
Example 2:
Integer a = 257;
Integer b = 257;
So, what is returned by printing a==b? a.equals(b)
According to the source code analysis in Example 1, we can know that when the value exceeds the range of -128~127, the Integer object will be newly created during auto-boxing, and the creation of the object is completed in the heap. Therefore, at this time, the stack The reference types a and b in the frame point to two objects (the reference type stores the address or handle address of the object). Therefore, we can clearly conclude that a==b prints false.
For a.equals(b), we need to look at the source part of equals in Integer. See Figure.
In the source code, we can clearly see that when using equals in the comparison of wrapper class objects, when the compared object is an instance of Integer, the equals method performs an unboxing operation, and returns the comparison result of value and value (257= =257), so, using equals to compare the returned result a.equals(b) returns true.
If it is not an instance of Integer, according to the source code, return false directly.