Comparing Integers and Longs

Discussion in 'Java' started by richnjones, Nov 20, 2007.

  1. richnjones

    richnjones Guest

    Hello all,

    Im a little confused on how number comparison is done. Consider

    1 Integer i = new Integer(5);
    2 Integer ii = new Integer(5);
    3 Long l = new Long(5);
    4
    5 System.out.println("two Integers " + (i == ii));
    6 System.out.println("Integers and Long.intValue " + (i ==
    l.intValue()));


    The output of this is

    two Integers false
    Integers and Long.intValue true

    The first false I can understand. Using new will create new objects so
    that the == will fail. (Correct me if I am wrong). The second output I
    expected to be false.

    This is how I see things...

    1 I have an integer object and a long object
    2 Doing l.intValue() will return an int which will be autoboxed up to
    an Integer
    3 This new Integer I thought would be a new object and so the ==
    should fail.

    Is the autoboxing being clever and seeing that there is another object
    with the same value and just assigning the reference to that? (Like
    with Strings)

    Why is the second output not false?

    TIA

    Richard
     
    richnjones, Nov 20, 2007
    #1
    1. Advertisements

  2. richnjones

    Chris Dollin Guest

    No.

    No Object is needed; no autoboxing need happen.
     
    Chris Dollin, Nov 20, 2007
    #2
    1. Advertisements

  3. Perhaps Integer.compareTo(Integer anotherInteger) will work.
    Someone will give you a more technical explanation, I'm sure.
    Even so, you don't usually compare objects with == but .equals()
     
    Sabine Dinis Blochberger, Nov 20, 2007
    #3
  4. richnjones

    richnjones Guest

    Thanks for your reply Chris,

    if not autoboxing is happening then the following code should output
    true

    1 int i = 5;
    2 Integer ii = new Integer(5);
    3 System.out.println(i == ii);

    which is does :)

    Im still not completely clear on how == can be used with primitives.
    My understanding is that == checks for object equality (the bit
    pattern of the object). Does anyone know how == works with primitives?

    TIA
    Richard
     
    richnjones, Nov 20, 2007
    #4
  5. Which is funny, because a lot of java-newbies find it just natural
    how primitives are handled, and have problems understanding "=="
    for the object-wrappers.
    "==" always compares primitive types: either it compares values
    (int,long,float,double,byte,short,...), or it compares references,
    but it never compares objects!

    To compare Objects, you'd use Object's .equals(other) method, as
    overloaded appropriately for any class that you actually use.

    PS: in (Integer == int)-type comparisons, Seemingly it unboxes
    the object, rather than box the primitive.
    You can verify this, by using javap (or whatever other
    class-file-disassembler) on your sample.class and see what it
    really does. ... it calls Integer's intValue() method, and
    does an int-compare. (if_icmpne)

    class A {
    public static void main(String[]args){
    Integer i1=new Integer(42);
    int i2=42;
    System.out.println( (i1 == i2) );
    }
    }
     
    Andreas Leitgeb, Nov 20, 2007
    #5
  6. There are two ways it could have been designed, the way you described
    and by unboxing the Integer to produce an int.

    The best place to look to find out which was chosen is the JLS
    description of ==. It says "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)."

    http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.21

    5.1.8 Unboxing Conversion permits Integer to int.

    5.6.2 Binary Numeric Promotion says "If any of the operands is of a
    reference type, unboxing conversion (§5.1.8) is performed."

    I think they made the right choice. A comparison between Integer and int
    would be pointless if it were done by boxing the int, but is very useful
    if done by unboxing the Integer. It also makes the same conversions
    apply to == for mixed types as apply to the binary arithmetic operators.

    Patricia
     
    Patricia Shanahan, Nov 20, 2007
    #6
  7. Thanks all! Thats a lot clearer

    R
     
    iamrichardjones, Nov 20, 2007
    #7
  8. richnjones

    Chris Dollin Guest

    That's not because of autoboxing; that's because of auto/un/boxing
    in the special treatment of `==`.
    By comparing their values.
    No: it compares values, not objects. That is, if its operands are
    primitive values, it compares those values; if they are references
    (ie a value of class/interface type) then it compares those references;
    and if they're mixed, it may apply autounboxing.
    It may come down to that, yes.
    In what sense? It compares their values. How else could it work?
     
    Chris Dollin, Nov 20, 2007
    #8
  9. I'd say confusing, not pointless. Assume:

    Integer ii;
    int i;
    i == ii.intValue();

    since autoboxing i is done with Integer.valueOf() (not new Integer()) there
    would be an implementation-specific range of values for which (i == ii) is
    true, but it would be false outside that range.
     
    Mike Schilling, Nov 20, 2007
    #9
  10. You missed out one of the conditions. If ii references an Integer that
    was created by new Integer(), the answer would be false even if i is in
    the range.

    I agree it would be confusing. I suppose it does provide a way to probe
    the internals of Integer at run time. I still contend the Java designers
    made the right choice.

    Patricia
     
    Patricia Shanahan, Nov 20, 2007
    #10
  11. richnjones

    Mark Space Guest


    Maybe this was mentioned somewhere, though I didn't see it.

    Reading line 3, I start with an int i, then see I ==, then I see an
    Integer. If I were a parser, I'd be temped to convert the Integer to
    the type of the existing expression (int in this case) first. Since I
    can do that, I'd unbox the Integer to an int and continue. Hence, ==
    will compare two int's and gives true as a result.

    I'm not sure, but that's what I speculate.

    Try switching i and ii above and see if you get a different result...
     
    Mark Space, Nov 20, 2007
    #11
  12. Why speculate, when the JLS tells all? Well, at least quite a lot,
    including the answer to this question.

    "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)."

    http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.21.1

    Patricia
     
    Patricia Shanahan, Nov 20, 2007
    #12
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.