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...
"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
Whizlabs Support (info@whizlabs.com or +91-9971838640 )
OCAJP 8 | OCPJP 8 | OCEJWCD | OCMJEA
Whizlabs Support (info@whizlabs.com or +91-9971838640 )
OCAJP 8 | OCPJP 8 | OCEJWCD | OCMJEA
Whizlabs Support (info@whizlabs.com or +91-9971838640 )
OCAJP 8 | OCPJP 8 | OCEJWCD | OCMJEA
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?
"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
Originally posted by veesam sridhar:
... Please confirm that Boxing/Unboxing(Type conversions) is in SCJP1.4 syllabus...
"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
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |