Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Agile forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Issue with equality and autoboxing

 
Junilu Lacar
Bartender
Pie
Posts: 7306
45
Android Eclipse IDE IntelliJ IDE Java Linux Mac Scala Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[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 ]
 
Jeroen Wenting
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Junilu Lacar
Bartender
Pie
Posts: 7306
45
Android Eclipse IDE IntelliJ IDE Java Linux Mac Scala Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Igor Ko
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think auto boxing/unboxing don't worth for such language complication.

Now you should spend more time to understand simple program, and for what ?
 
Junilu Lacar
Bartender
Pie
Posts: 7306
45
Android Eclipse IDE IntelliJ IDE Java Linux Mac Scala Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


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 ]
 
Junilu Lacar
Bartender
Pie
Posts: 7306
45
Android Eclipse IDE IntelliJ IDE Java Linux Mac Scala Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here's a stupid trick that I tried using JDK 1.5.0 beta 2:



Just because you can do it doesn't mean you should.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic