This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Primitives and auto-boxing transparency Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general. Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Cincom Smalltalk Blog - Smalltalk with Rants

Patrick Logan points to some pages with some "surprises" for Java developers using auto-boxing. This is the one that tosses some people:

Integer i1 = new Integer( 2);
  Integer i2 = new Integer( 2);
  System.out.println( i1==i2);

  Integer j1 = 2;
  Integer j2 = 2;
  System.out.println( j1==j2);

The interesting issue is that the first answers false, the second true. Now, this isn't a huge surprise; the "==" is doing an identity check - in Smalltalk, this gives you false as well:

1.5 == 1.5

It's an artifact of optimization that 2 == 2 gives you true in Smalltalk. The reason this generates some confusion in Java-land is that an equality check takes more work to write out - recall that "=" is assignment in Java (I didn't recall this at first - it's been too many years since I did C). So to get an equality check:

Java

"hello".equals "hello"

In Smalltalk:

'hello' = 'hello'

And of course, you can override #= in your own classes in order to create a localized definition of equality. The upshot is, people tend to write == in Java where they should be using equals() - and now auto-boxing is going to bite them when they do that. Just look at the comment thread here for an example of the confusion. The problem arises because you can "get away" with using the == operator when using primitive data types. You'll then get bitten if you let the habit carry over to using the new auto-boxing feature. This is another one of those cases where creeping complexity ends up being a real problem...