If the value p being boxed is true, false, a byte, a char in the range \u0000 to \u007f, or an int 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... Ideally, boxing a given primitive value p, would always yield an identical reference. In practice, this may not be feasible using existing implementation techniques. The rules [linked to] above are a pragmatic compromise...
In other words, two autoboxed instances of Integer, for example, will have equal references (==) if their wrapped values are equal and within byte range, -128 to 127. Outside of this range, there is apparently no guarantee...
On my platform (Mac OS 10.4 running Apple's first release of Java 5.0), I get true in the first case, but false in the second. The first case should be expected on all platforms, but (as I interpret this) the second case is not guaranteed.
Aside from that little detail, I'm not sure what you mean by "twisted cases." Do you have something specific in mind? [ October 22, 2005: Message edited by: marc weber ]
"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer sscce.org
Joined: Oct 12, 2005
For example this is an error. String s=null; int i=0; if(s==i);
The rule that I've learned by testing is. The boxing will occur if the requested type is a superclass. Then if the boxing takes place the boxed type is determined by the type of the primitive. If the requested type is not a superclass, then no boxing takes place.
I haven't tested this, so I don't know if it even compiles. If it does, is the right side of each == operation being unboxed to a primitive or is the right being boxed to a wrapper? I think I will test this further on my own...
Boxing conversion converts values of primitive type to corresponding values of reference type. Specifically, the following 8 conversion are called the boxing conversions:
* From type boolean to type Boolean * From type byte to type Byte * From type char to type Character * From type short to type Short * From type int to type Integer * From type long to type Long * From type float to type Float * From type double to type Double
Originally posted by Joan Pujol: ... The rule that I've learned by testing is. The boxing will occur if the requested type is a superclass. Then if the boxing takes place the boxed type is determined by the type of the primitive. If the requested type is not a superclass, then no boxing takes place. Is this rule true?
That's not accurate. As Krishna pointed out (and as outlined in the JLS link I posted above), boxing applies only to primitives and their corresponding wrappers. It has nothing to do with superclass/subclass relationships.
Autoboxing will take place if a wrapper object is expected and an appropriate primitive is provided. For example, if you declare Integer intObj and then assign intObj = 1. Because a wrapper object is expected, the primitive int is boxed.
Or perhaps you are confusing boxing with the widening conversions that take place with comparisions like ==. For example, if you have a short s and an int i, then s == i will widen the short to type int for the comparison.
Joined: Oct 12, 2005
A lot of thanks to all. The Krishna's link is very good. Is what I needed
But after reading it I think that my rule is not bad. But I wrote it a little bad. I rewrote it:
If where a primitive type is, there is expected a superclass of the wrapper for the primitive type the boxing takes place. If not expected a superclass of the wrapper of the primitive the boxing don't take place.
You can find a counterexample? For example it works with:
Number n= 5; //Boxing OK Float f= 5; //ERROR Boxing not ok Object= 6; //OK Boxing OK
I can find a little counterexample of and old post that I made. If we have B==b (where b is boolean and B is Boolean. The b isn't boxed, the B is unboxed. And in general with == or != if a primitive and a Wrapper are involved, always the operation is done with the primitives.
I think that this is bad in the Krishna's link that says: But when we come to the equals operator, ==, the JVM interprets that as the operator for object equality, rather than unboxing ivar2 and testing mathematical equality. Becaus JLS say: 15.21.1. Numerical Equality Operators == and != If the operands of an equality operator are both of numeric type, or one is of numeric type and the other is convertible (�5.1.8) to numeric type, binary numeric promotion is performed on the operands (�5.6.2).