evolutionnext

Integer i = new Integer(2);
Integer j = new Integer(2);
assertTrue(i >= j); // success
assertTrue(i <= j); // success
assertTrue(i == j); // failure!

assertTrue(i.equals(j)); // success, at last

String name = "Jack"
StringBuffer s = new StringBuffer("Hello ").append(name).append(", how are you?");
System.out.println(s.toString());

"If the value p being boxed is true, false, a byte, an ASCII character, or an integer or short number between -128 and 127, then let r1 and r2 be the results of any two boxing conversions of p. It is always the case that r1 == r2."

This was not implemented in the first Beta of Java 1.5, but it is in the second Beta.

Daniel: Yes, of course you still need to teach primitives, because you cannot perform arithmetic operations on wrapper classes. And an "if" statement still requires a boolean and not a Boolean, and a "case" statement still requires an integer type and not an Object. As soon as you get beyond "println()", you quickly need primitives.

Using "new Integer()" does indeed give distinct objects; that's a fundamental requirement of "new". Autoboxing or valueOf() will use shared objects for small values.

Maybe next time I'll read more closely before commenting :-)

Doug, my example does illustrate autoboxing, just from a different point of view: in fact, you couldn't use operators like '>=' on Integer objects without autoboxing. (I'm talking about that particular feature of autoboxing which is auto-unboxing, of course.) Indeed, you fans of the so-called "documented behaviour" should have a look at the first three chapters in The Hitchhiker's Guide to the Galaxy by Douglas Adams. ;)

Stefan: try Ruby for a taste of a completely object-oriented language. It lets you write the following, where you don't even need a weird string substitute for a symbolic operator.

5 + 2 # returns 7
5.+(2) # returns 7, again

I like the approach. On the very same note, I like also the following Java approach towards String literals.

String name = "Jack";
String s = "Hello " + name + ", how are you?";

Which, since before autoboxing was the only operator overloading example contained in the Java language, pretty much works on the same principle; you just can't directly call the method behind the '+' operator.

On the other hand, performance could be an issue, as you asserted. What about the following cycle, picked up in a comment to another post on the same autoboxing topic?

for (Integer i = 0; i < 100000; i++)
    // do something...

I've read elsewhere that in his Effective Java, Joshua Block advised people to use StringBuffer's capabilities to concatenate strings because of poor performance of concatenation of string literals. But that was in 2001. Anyway, performance issues concerning autoboxing are definetely something to check out.

So, another approach to the problem of autoboxing potential confusion, an approach completely different from the one I was advocating in my previous comment, could be to use primitive types everywhere, and let autoboxing deal with code using collections:

int one = 1;
ArrayList list = new ArrayList();
list.add(one + 1); // automatically converted to an Integer object
int two = list.get(0); // automatically converted to an int

which, by the way, I think was the main reason behind the introduction of autoboxing in the Java language. After all, as I have already said, Java is still not a completely object-oriented language despite autoboxing magic, so why should we pretend that it is?

String name = "Jack";
String s = "Hello " + name + ", how are you?";

Oh, well, you can. It is called concat:

String s = "Hello".concat(name).concat(" how are you?");

Sorry, my mistake.