File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Implicit casting with primitives/wrapper classes Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Implicit casting with primitives/wrapper classes" Watch "Implicit casting with primitives/wrapper classes" New topic
Author

Implicit casting with primitives/wrapper classes

Vivek Gorade
Greenhorn

Joined: Nov 14, 2009
Posts: 6
Hello Ranchers,

I have hit a roadblock while trying to understand implicit casting especially wrt wrapper classes.

Case1- primitives
This works-
short sh=7;

This doesnt-
public void callToMethod(short sh);
callToMethod(7);

If it could cast integer to short using = operator, why couldnt it do the same thing during method invocation?



Case 2 - wrapper

Short SH=new Short("23");
Integer In=new Integer(23);
int in=23;
if (SH <= In){/*works*/} //1
if (SH >= 7){/*works*/} // 2
if (SH == In){/*compiler complains*/}; // 3 Incompatible operand types Short and Integer

Apparently, when Short was compared with Integer, compiler seemed happy. When Short was compared with 7, it didnt require explicit casting. I am not able to catch up on what difference == made. Now I am not certain whether I am clear with basics of implicit casting.
Dejan Miler
Ranch Hand

Joined: Nov 14, 2009
Posts: 56
Hi.
First of all we cannot put integer value like method parameter because we all know that short is smaller then an int.
Java is pass-by-value so in our case the whole value will be copied and java has insure only that much memory for short value (16bits)

For second part
you cannot compare Integer and Short and expect that thy are the same (Two different kind of object)
operator == compare is two object are of same type, and when we compare wrapper type (Integer) with lets say short unboxing take place.
And when we compare two wrapper class with >,<,<= or >= unboxing take place as well.
Sorry for my english

SCJP 1.6 in progress ....
Ankit Garg
Sheriff

Joined: Aug 03, 2008
Posts: 9321
    
  17

1. Implicit downcast doesn't apply to method calls. That's the way it is. When you assign 7 to a short using = operator, there's an implicit downcast, but that's not applicable to method calls.

2. When you compared Short and Integer using > or < ro >= or <=, then the compiler knew that the only way to compare them is to unbox them. So automatic unboxing was done. But when you compared Short and Integer using ==, then the compiler didn't do unboxing (as two reference variables can be compared using ==). And since Short and Integer are not in the same class hierarchy (i.e. they are siblings and they are also final), thus the comparison failed...


SCJP 6 | SCWCD 5 | Javaranch SCJP FAQ | SCWCD Links
Vivek Gorade
Greenhorn

Joined: Nov 14, 2009
Posts: 6
For primitives, is it okay to assume that implicit casting will occur only when assignment operator is used? (given that new size is appropriate)
Wrapper explanation was helpful. Thank you. It failed because == tried to compare references, which are not equal. I find it a bit strange that it also casted the SHORT to int after unboxing it, to compare against 7.
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 19061
    
  40

There are actually a few things going on (in addition to implicit casting) and they seem to be getting mixed in, with the conclusions being drawn...

Vivek Gorade wrote:For primitives, is it okay to assume that implicit casting will occur only when assignment operator is used? (given that new size is appropriate)


Implicit casting (widening) works with both assignments and with method calls. The "implicit casting" that you are referring to (narrowing "given that the new size is appropriate") actually falls under the compile time constant rules, and it is that that allows the assignment to compile.

Vivek Gorade wrote:Wrapper explanation was helpful. Thank you. It failed because == tried to compare references, which are not equal. I find it a bit strange that it also casted the SHORT to int after unboxing it, to compare against 7.


Casting a short to an int is always allowed implicitedly -- as that is a widening cast. Regardless, this second question is not really about implicit casting, but when unboxing takes place.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Vivek Gorade
Greenhorn

Joined: Nov 14, 2009
Posts: 6
Hi Henry,

Thanks.
Are there any other compile time constant rules with respect to narrowing? Could someone please point me to any online reference(or book) to refer to, for detailed explanation of these rules.

Vivek
Ninad Kulkarni
Ranch Hand

Joined: Aug 31, 2007
Posts: 802

Are there any other compile time constant rules with respect to narrowing? Could someone please point me to any online reference(or book) to refer to, for detailed explanation of these rules.

@ Vivek
You can refer JLS 3.0
Narrowing Primitive Conversions
And also refer to Henry Wong's in-depth explanation about compile time constant.


SCJP 5.0 - JavaRanch FAQ - Java Beginners FAQ - SCJP FAQ - SCJP Mock Tests - Tutorial - JavaSE7 - JavaEE6 -Generics FAQ - JLS - JVM Spec - Java FAQs - Smart Questions
Vivek Gorade
Greenhorn

Joined: Nov 14, 2009
Posts: 6
Thanks. Important point from JLS (Will append if I find more)-

Method invocation conversions specifically do not include the implicit narrowing of integer constants which is part of assignment conversion (§5.2). The designers of the Java programming language felt that including these implicit narrowing conversions would add additional complexity to the overloaded method matching resolution process (§15.12.2).

Thus, the example:

class Test {
static int m(byte a, int b) { return a+b; }
static int m(short a, short b) { return a-b; }
public static void main(String[] args) {
System.out.println(m(12, 2)); // compile-time error
}
}

causes a compile-time error because the integer literals 12 and 2 have type int, so neither method m matches under the rules of (§15.12.2). A language that included implicit narrowing of integer constants would need additional rules to resolve cases like this example.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Implicit casting with primitives/wrapper classes