aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Boxing/Unboxing Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Boxing/Unboxing" Watch "Boxing/Unboxing" New topic
Author

Boxing/Unboxing

Joan Pujol
Ranch Hand

Joined: Oct 12, 2005
Posts: 54
Hello,

Some know a good resource to learn the exact rules for boxing/unboxing. I know the rules for normal cases. But in some twisted cases it's difficult to me to predict the behaivour.

I've tried to look at JLS but the info is a little disperse in various sections...
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

Have you seen this part of the JLS...?

http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#5.1.7

Here's one potential "twist" outlined in the JLS:
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
Joan Pujol
Ranch Hand

Joined: Oct 12, 2005
Posts: 54
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.

Is this rule true?
Layne Lund
Ranch Hand

Joined: Dec 06, 2001
Posts: 3061
I might test this out with some other examples:

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...

Layne


Java API Documentation
The Java Tutorial
Krishna Srinivasan
Ranch Hand

Joined: Jul 28, 2003
Posts: 1844

This link will help you :
http://today.java.net/pub/a/today/2005/03/24/autoboxing.html


Krishna Srinivasan
Spring Tutorials, OCAJP Mock Questions, 400+ OCPJP Mock Questions
Krishna Srinivasan
Ranch Hand

Joined: Jul 28, 2003
Posts: 1844

Aouto boxing is applicable only for Wrapper typea and primitives. We cannot use with strings. If you want to convert from Wrapper to Primitive vice versa.
Krishna Srinivasan
Ranch Hand

Joined: Jul 28, 2003
Posts: 1844

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
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

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.
Joan Pujol
Ranch Hand

Joined: Oct 12, 2005
Posts: 54
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).
Ray Horn
Ranch Hand

Joined: Oct 20, 2005
Posts: 39
Well written article Krishna Srinivasan. Promotion to author from ranch hand in the cards.
[ October 23, 2005: Message edited by: Ray Horn ]
veesam sridhar
Ranch Hand

Joined: Oct 18, 2005
Posts: 51
hi,

Please confirm that Boxing/Unboxing(Type conversions) is in SCJP1.4 syllabus.I did not across about this in K&B book.

Thanks.
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

Originally posted by veesam sridhar:
... Please confirm that Boxing/Unboxing(Type conversions) is in SCJP1.4 syllabus...

Boxing/unboxing is a new feature with Java 5.0. It is not included in 1.4.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Boxing/Unboxing
 
Similar Threads
question on return type
assertion
Method matching.
Doubt in Overloading
Widening, Boxing & Vararg and Overloading Confusion