[shameless plug]Please see my blog entry [/shameless plug] about the issue of losing transitivity of equality with autoboxing, discussed in a recent JavaWorld article. Does my reasoning hold water or am I way out in left field on this? [ June 15, 2004: Message edited by: Junilu Lacar ]
I think the idea that autoboxing should cause == to work on object content for wrapper classes rather than on the object references (as you seem to imply) is a bad one. It would effectively break the wrapper classes out of the Java object hierarchy and force overloaded operators to be introduced for them.
The situation is bad enough trying to explain to people why == shouldn't be used to compare Strings, now if it SHOULD (or could) be used to compare Objects of some other classes that would get a lot worse.
Originally posted by Jeroen Wenting: I think the idea that autoboxing should cause == to work on object content for wrapper classes rather than on the object references (as you seem to imply) is a bad one.
Are you saying that:
To me, the latter is more in line with the stated purpose of autoboxing/unboxing which is to eliminate the drudgery of manually converting from primitive to wrapper and vice versa. I would think that if you wanted the former and still have autoboxing, you'd have to write
instead. If (a == b) were equivalent to (a.equals(new Integer(b)), not only are you automatically converting the type of the variable b, you're also changing the == operator to behave like a call to the equals() method of the Wrapper class. That would be even more confusing because it's doing two things rather than just the one thing of unboxing the int value from a and then performing the == operation as normal.
Think about it, you don't say Anti-lock Braking Systems are a bad thing for cars because some people don't know to keep stepping on the brake pedal to make it work right. Likewise, I don't think we should be too quick to judge autoboxing/unboxing because stupid things can be done with them. [ June 16, 2004: Message edited by: Junilu Lacar ]