[Rick]: Either have == always compare the values when it comes to the wrapper objects that are numbers or Boolean or else stick to having it always comparing references
Um, it is
always comparing the references. It's just that within the specificed ranges, instances are cached and reused for autoboxing. This means that for example a 1 always autoboxes to the same Integer instance. Which does lead to some strange behavior, but ultimately it's just another example of the general rule: don't use == to compare reference objects unless you're sure you really want to compare object identity, and know exactly what that entails. This is much like the way two identical Strings may or may not turn out to be the same instance, depending on whether the String
pool was involved in their creation. Which is also confusing, but people learn to avoid it. The problem here is just that autoboxing is still new to many people, and its transparency means that people often don't realize what is going on.
Now if we were designing a new language, I much prefer what Groovy did, which is to define == as always meaning an equals() comparison (with appropriate null check) when dealing with reference objects. The rare cases where identity comparison is really desired are handled with a new operator, ===. But for standard Java, we're stuck with a certain amount of ugliness from retroactive compatibility with design decisions made over a decade ago.
[ October 16, 2006: Message edited by: Jim Yingst ]