First, let's look at a piece of code (using JDK 5), as follows: public class test {
Public static void main (string [] ARGs ){
Integer I1 = 127;
Integer I2 = 127; If (I1 = I2)
System. Out. println ("Equal! ");
Else
System. Out. println ("not equal! ");
}
} The output result must be "Equal !". Now, change the I1 and I2 values from 127 to 128 to see what will happen? The result output is "not equal !".
Tip: the explanation is incorrect. you can skip the following.Note that I1 and I2 are both integer types. In fact, as long as the value range is between "-128-127", the output result is "Equal !". JDK 5 introduces many new features, including autoboxing and auto-unboxing ). When the I1 and I2 values are 128, they are loaded into two different integer objects during "=". Because these are two different instances, they reference different memory addresses, so the result is "not equal! ". However, when the value is 127, JVM automatically converts the value to an int of the basic type. In this way, "=", the JVM still uses the same object instance, therefore, the output result is "equal!" . Really annoying!
Modified:
First of all, I would like to thank abcdhy for pointing out the problem. In order to spur myself more, I will keep the explanation of the above errors, and remind myself that we must be down-to-earth in researching the problem and make multiple research efforts. For convenience, I wrote the following code: public class test {
Public static void main (string [] ARGs ){
Integer I1 = 127;
Integer I2 = 127;
Integer I3 = integer. valueof (127); If (I1 = I2)
System. Out. println ("I1 = I2 is true! ");
Else
System. Out. println ("I1 = I2 is false! "); If (I1> = I2)
System. Out. println ("I1> = I2 is true! ");
Else
System. Out. println ("I1> = I2 is false! "); If (I1 = I3)
System. Out. println ("I1 = I3 is true! ");
Else
System. Out. println ("I1 = I3 is false! ");}
}
If the value is 127, the output is:
I1 = I2 is true!
I1> = I2 is true!
I1 = I3 is true!If the value is 128, the output is:
I1 = I2 is false!
I1> = I2 is true!
I1 = I3 is false!Note: I am using Sun JDK 1.5.0 _ 03-b07 and eclipse 3.2m4. The error "Type Mismatch: cannot convert from int to integer" is prompted when "integer I1 = 127;" cannot be compiled under jdk1.4. It is generally rewritten: "integer I1 = new INTEGER (127 );". "Integer I1 = 127;" can be compiled in jdk1.5, Which is autoboxing and auto-unboxing ). The autoboxing feature enables Java to automatically wrap a simple data type (such as INT) to the corresponding packaging type (such as integer. In 《
Jsr201: Extending the Java programming language with enumerations, autoboxing, enhanced for loops and static import:
If the value p being boxed is true, false, a byte, an ASCII character, or an integer or short number between-127 and 128, then let R1 and R2 be the results of any two boxing conversions of P. it is always the case that R1 = R2.In Java, the following is the list of primitives stored
Immutable objects (Immutable object
): * Boolean values true and false
* All byte values
* Short values between-128 and 127
* Int values between-128 and 127
* Char in the range/u0000 to/u007f for easier understanding, use Jad to decompile the above Code, as shown below: Import java. Io. printstream; public class test
{Public test ()
{
} Public static void main (string ARGs [])
{
Integer I1 = integer. valueof (128 );
Integer I2 = integer. valueof (128 );
Integer I3 = integer. valueof (128); If (I1 = I2)
System. Out. println ("I1 = I2 is true! ");
Else
System. Out. println ("I1 = I2 is false! "); If (i1.intvalue ()> = i2.intvalue ())
System. Out. println ("I1> = I2 is true! ");
Else
System. Out. println ("I1> = I2 is false! "); If (I1 = I3)
System. Out. println ("I1 = I3 is true! ");
Else
System. Out. println ("I1 = I3 is false! ");
}
}
From this we can see that "integer I1 = 127;" should be compiled into "integer I1 = integer. valueof (127);" in JDK );". Let's take a look at the source code of valueof in Java. Lang. Integer: public static integer valueof (int I ){
Final int offset = 128;
If (I> =-128 & I <= 127) {// must Cache
Return integercache. cache [I + offset];
}
Return new INTEGER (I );
} It can be seen that the value range is-128 to 127, and its cached (cache) will be used. If it is used for multiple times, it will save memory and improve performance. If it is not in this range, A new integer object instance is generated. Therefore, when "=" is performed, the result is false because two different object references are compared. In fact, this feature exists from JDK 1.3 (I don't know before ). Specifically, the problem above is actually not autoboxing or auto-unboxing. It should be the valueof (int I) method of the integer class, it's just that autoboxing and auto-unboxing cover up this problem.
