Mailing Lists: Apple Mailing Lists

Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: wrong behaviour when checking the equality of two elements of an ArrayList<Integer> using the operator "=="



At 5:00 PM +0100 7/9/07, Francesca De Angeli wrote:
I hope this will not be considered as a misuse of the java-dev mailing list. The issue I am reporting is probably not relevant for most developers but I came across it and I was very surprised.

Imagine creating an ArrayList of Integers

ArrayList<Integer> list = new ArrayList<Integer>();

and adding elements to it. You can do this is two ways (at least):

1) you may have some primitive of type int and you may add that directly to your ArrayList

	list.add(myPrimitiveInt);

2) or you can create the Integer object from the primitive

	list.add(new Integer(myPrimitiveInt));

Now imagine to do the following:

int myPrimitiveInt = 4;
ArrayList<Integer> list = new ArrayList<Integer>();
list.add(myPrimitiveInt);
list.add(myPrimitiveInt);

What really surprises me is that now you will get true from the condition (list.get(0) == list.get(1)) !
This is really unexpected as the method ArrayList.get(int) returns an Integer object not a primitive and the == operator should check if the two objects are the same and not if their value is the same.


In fact if you do the following:

int myPrimitiveInt = 4;
ArrayList<Integer> list = new ArrayList<Integer>();
list.add(new Integer(myPrimitiveInt));
list.add(new Integer(myPrimitiveInt));

the condition (list.get(0) == list.get(1)) will return false as expected.
I checked with several other JVMs on different platform and none of them gave this weird result (i.e. all of them gave false in both cases).


Has anybody else come across this before? Do Apple has a place where you can post bugs of this type? Is there some obvious thing I am missing?

Many thanks. Cheers,
Francesca

This is not unique to the Mac environment. I'm able to reproduce what you've described in Windows XP and Java 5.


I'm not 100% certain that I understand the explanations I've seen thus far in the Java Language Specification (JLS), but I *think* this can be explained as proper behavior (albeit questionable correctness, I think) resulting directly from the use of Java 5's new "auto-boxing" features. Refer to JLS sections 5.1.7 on Boxing Conversion and 5.1.8 on Unboxing Conversion.

I began with a look at 15.21 on the subject of the equality operator ('==') and noted a link to 5.1.8 on conversion. What I *think* I understand is that some internal trickery (for lack of a better description) is going on when so-called "boxing conversion" is used to store the primitive. As a result, in your first example, the explicitly created Integer object is in the list, but the JVM built something around the primitive. When it's "converted" on extraction, it's being compared by intValue and not reference value...if I'm correct in my thinking on this.

= Steve =
--
Steve W. Jackson
Montgomery, Alabama
http://homepage.mac.com/stevejackson/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden

This email sent to email@hidden
References: 
 >wrong behaviour when checking the equality of two elements of an ArrayList<Integer> using the operator "==" (From: Francesca De Angeli <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.