AutoBoxing , AutoUnBoxing

AutoBoxing:
• Automatic conversion by the compiler from primitive type to the corresponding object form is called AutoBoxing.
Ex: int i=10; //Compile time error in 1.4 but valid in 1.5
Integer I=i;
• Compiler first constructs the integer object and then assigned that object to the variable.
AutoUnBoxing:
• Automatic conversion from wrapper class object to primitive type by the compiler is called AutoUnBoxing.
Ex: Integer I= new Integer(10);
int i= I; //CTE :1.4
// valid in 1.5

* The compiler coverts Integer object to primitive and that primitive value will assign to variable i.


* Because of these new autuboxing or auto unboxing features, the importance of wrapper classes is not that much in the 1.5 version.
AutoBoxing in expressions:
Integer y=10;
Integer x=y;
Y++;
System.out.println(x); // 10
System.out.println(y); // 11
System.out.println(x==y); // flase
Wapper class objects are immutable .if you want to perform any changes with those changes a new wrapper class object will create.
Special cases:
case1:
Integer i1=new Integer(10);
Integer i2=new Integer(10);
System.out.println(i1==i2); //false
Case2:
Integer i1=new Integer(10);
Integer i2=10;
System.out.println(i1==i2); //false
Case3:
Integer i1=100;
Integer i2=100;
System.out.println(i1==i2); //true
Case4:
Integer i1=1000;
Integer i2=1000;
System.out.println(i1==i2); //false
In the case of autoboxing compalier won’t create any new object If an existing already created object mapped with the reqired one . the existing object should be created bt the autoboxing only.
This poosibility will occur in the following cases.
1.By using autoboxing. If it is required to create a new wrapper object, other wise compiler won’t create any new object, if already an object is present in the fallowing cases. these Objects are Boolean and Byte.
2. Character object ranges from 0 to 127 ------> (‘\u0000’ to ‘\u0007f’).
3. For the integer and short if the value is less than or equal to 127.
4. For the long of the value is less than or equal to 127 L .
But Long l=10; //invalid
CTE: incompatable types
Found:int , req: java.lang.Long
Similarly Float f= 10; //invalid - CTE: incompatable types
Found: int, req: java.lang.Float
Case5:
Boolean b1=true;
Boolean b2=true;
System.out.println(b1==b2); // true
Case6:
Boolean b3=flase;
Boolean b4=flase;
System.out.println(b3==b4); // true

Special case:
Example:
class Sample
{
static Integer I1=10; ---->I1: Initialized
public static void main(String a[])
{
m1(I1); ---> I1 : auto unboxing
}
public static void m1(int i)
{
Integer I2=i; ----> I2: auto boxing
System.out.println(I2); //10
}
}
above example executes fine.
But
class Sample
{
static Integer I1; // not Initialized
public static void main(String a[])
{
m1(I1); // null pointer exception
}
public static void m1(int i)
{
Integer I2=i;
System.out.println(I2);
}
}
Static variables by default initialized with null, which can’t be autoboxing/autounboxing.Hence Run time exception.

overloading when combining with widening and Autoboxing:
class Text
{
static void m1(Integer x)
{
System.out.println(“integer”);
}
static void m1(long l)
{
System.out.println(“long”);
}
public static void main(String arg[])
{
int i=5;
m1(i); //long
}
}
when comparing widening with autoboxing compiler always prefers widening in order to provide the sport for legacy code.
Over loading in case of widening with var-arg method:
Class sample
{
static void m1(int I,int j)
{
System.out.println(“int, int”);
}
static void m1(byte… b)
{
System.out.println(“byte arg”);
}
public static void main(String arg[])
{
byte b=5;
m1(b,b);
}
} // in tint
widening dominates var-arg method .compiler will give the precedence for widening over var-arg method.
Autoboxing vs var-args:
Class Sample
{
static void m1(Byte b)
{
System.out.println(“byte”);
}
static void m1(byte… b)
{
System.out.println(“byte arg”);
}
public static void main(String arg[])
{
byte b=5;
m1(b);
}
}
the compiler prefers autoboxing over var-args
If there is no other method matched,then only var-arg method always seeks to least priority.
Conclusion:
The compiler always gives the precedence in the following order for resolving over loading methods.
1.wid4ening
2.auto boxing & unboxing
3.var- args
Special cases:
Class Sampe
{
public static void m1(Long l)
{
System.out.println(“long”);
}
public static void main(String arg[])
{
byte b=5;
m1(b);
}
}

In java widening followed by autoboxing is not allowed.Hence the above code raise a CTE saying m1(java.lang.long) in sample can not be applied to (byte).
i.e Byte --------> Long is not possible.
But byte ----->long is possible.
Widening followed by autoboxing is not allowed. But the reverse is allowed in java i.e autoboxing follwed by widening is possible.
Class Sample
{
static void m1(Object o)
{
System.out.println(“object”);
}
public static void main(String arg[])
{
byte b=5;
m1(b); // object
}
}
i.e byte -----> Byte -----> Object
i.e Here autoboxing is followed by widening .

class Samle
{
static void m1(byte… b)
{
System.out.println(“byte……”);
}
static void m1(byte b,byte… b1)
{
System.out.println(“byte, byte….”);
}
public static void main(String arg[])
{
byte b=5;
m1(b); // CTE saying reference to m1 is ambiguous.
}
}
Here both methods are matched because of var-args feature.Hence compailer can’t give any precedence results in CTE
Static variable by default initialized with null,which can’t be autoboxing /autounboxing