Autoboxing in Java

Question

How does following expression evaluated?

Student class :

public class Student
{
    private Integer id;
    // few fields here

    public Integer getId()
    {
        return id;
    }

    public void setId(Integer id)
    {
        this.id=id;
    }

    //setters and getters
}

And in some method :

{
    int studentId;

    // few lines here

    if(studentId==student.getId())  // **1. what about auto-unboxing here? Would it compare correctly? I am not sure.**
    {
        //some operation here
    }
}

Langobardic

Don't use the wrapper classes unless you absolutely have to. – Marsiella

Yes. what you did would work. I'm not sure you asked anything else? – Sandy

+1 for not using the wrapper classes: bad potential side-effect includes unwanted (and hidden) NullPointerException thrown by your code – Sandy

Answer 1

Yes, this will work it is equivalent to

studentId==student.getId().intValue()  

as long student.id is not null.

Expectorant

Just out of curiosity, what are the rules of boxing and unboxing? I mean, why does Java decide to unbox the Integer rather than box the int ? – Porkpie

it's equivalent whether student.id is null or not – Altaf

May be because int on the left? – Crenation

System.out.println(student.getId()) call toString() for Integer. – Crenation

@Max - most of the time with (un)boxing there's a specific target type, e.g. the declared class of a method parameter or variable. In this particular case, see JLS 5.6.2 for "Numeric Promotions", which states that If any of the operands is of a reference type, unboxing conversion (§5.1.8) is performed. – Triplet

Check out this link: docs.oracle.com/javase/1.5.0/docs/guide/language/… – Sandy

System.out.println(student.getId()) will print the int's toString() representation... – Amorino

@Max The specification is JSR 201 jcp.org/en/jsr/detail?id=201 . Another option would have been new Integer(intval).equals( intObj ) which would create a superflous objcet. – Expectorant

Answer 2

Yes this will work, but note!

If the Integer value id in Student is null, you will have a NullPointerException when evaluating

studentId == student.getId();

Note also that autoboxing will have some performance cost, so you should only use it if you have to.

Read more here: http://docs.oracle.com/javase/1.5.0/docs/guide/language/autoboxing.html

Cattleman

Answer 3

Yes it will work fine. But it is usually not advisable to use wrapper class until there is not other go.

Octosyllable

Answer 4

The comparison

studentId==student.getId()

will work, but will throw a NullPointerException if student is null.

As a rule autoboxing prefers primitives, i.e. it will convert an Integer to int where possible rather than the other way around. Your example shows one good reason for this, since equality for reference objects is tricky. So it is possible for:

studentId==student.getId().intValue()  

to be true but

new Integer(studentId)==student.getId()

to be false, since whilst they have the same value they're not the same object.

Shirtwaist

Answer 5

Yes it will work, as it will convert right operand to corresponding numeric type, according to java language specification:

If the operands of an equality operator are both of numeric type, or one is of numeric type and the other is convertible (§5.1.8) to numeric type, binary numeric promotion is performed on the operands (§5.6.2).

corresponding paragraph in jls

So actually any of the operands can be of numeric type for java to autounbox the other one.

And then §5.1.8 says that conversions include unboxing conversion.corresponing paragraph in jls

Pert

Answer 6

As per specifications, http://docs.oracle.com/javase/1.5.0/docs/guide/language/autoboxing.html

So when should you use autoboxing and unboxing? Use them only when there is an “impedance mismatch” between reference types and primitives, for example, when you have to put numerical values into a collection. It is not appropriate to use autoboxing and unboxing for scientific computing, or other performance-sensitive numerical code. An Integer is not a substitute for an int; autoboxing and unboxing blur the distinction between primitive types and reference types, but they do not eliminate it.

The only advisable cases to use the wrapper classes (Integer, etc.) are when you want to stick numeric values in a collection, or null is an acceptable value for your use-cases. That's it.

Side-effect include unwanted potential NullPointerException and decrease in performance.

Sandy