Implicit vs explicit numeric promotion

[Melissa Nikolic]

Hi again,

I wanted to confirm a particular conversion example and its meaning.

If I initialize the following:

short h = 40;

My Java book says that this is ok because int is converted to a short.

while...

h = h + 2; is not okay because "cannot assign an int to short"

Is this an error because the first example is explicitly assigned to a short while the second example is not explicitly assigned and therefore cannot be promoted implicitly?

Thank you for your assistance.

M

[Jeff Verdegan]

Melissa Nikolic wrote:Hi again,

I wanted to confirm a particular conversion example and its meaning.

If I initialize the following:

short h = 40;

My Java book says that this is ok because int is converted to a short.

while...

h = h + 2; is not okay because "cannot assign an int to short"

Is this an error because the first example is explicitly assigned to a short while the second example is not explicitly assigned and therefore cannot be promoted implicitly?

Case 1: 40 is an int. Since it is a compile-time constant that fits into a short, a narrowing conversion is automatically applied and the value (short)40 is stored in h. No promotion occurs.

Case 2: h + 2 is short + int, so the value of h on the RHS is promoted to an int, and the result of h + 2 is an int. Since h + 2 is not a compile-time constant, no automatic narrowing is done, and it's an error because we're trying to stick an int into a container meant to hold only a short.

[Campbell Ritchie]

I have already told you the Java Language Specification is difficult to understand, but that is where you will find the details.

[Melissa Nikolic]

Campbell Ritchie wrote:I have already told you the Java Language Specification is difficult to understand, but that is where you will find the details.

Thank you for the information. I will take heed and look in the Java documentation before posting. I will also ensure to cite the relevant reference therein to further highlight my question (or perhaps at that point questions, as you have mentioned it is difficult to understand).

Ultimately, being able to answer all of my own questions is preferable.

Regards,

M

[Melissa Nikolic]

Jeff Verdegan wrote:

Melissa Nikolic wrote:Hi again,

I wanted to confirm a particular conversion example and its meaning.

If I initialize the following:

short h = 40;

My Java book says that this is ok because int is converted to a short.

while...

h = h + 2; is not okay because "cannot assign an int to short"

Is this an error because the first example is explicitly assigned to a short while the second example is not explicitly assigned and therefore cannot be promoted implicitly?

Case 1: 40 is an int. Since it is a compile-time constant that fits into a short, a narrowing conversion is automatically applied and the value (short)40 is stored in h. No promotion occurs.

Case 2: h + 2 is short + int, so the value of h on the RHS is promoted to an int, and the result of h + 2 is an int. Since h + 2 is not a compile-time constant, no automatic narrowing is done, and it's an error because we're trying to stick an int into a container meant to hold only a short.

Thank you for your clear explanation. Frankly, telling a newbie to go to the Java documentation is like telling an introductory biology student to go find the answer to a question in a peer reviewed journal. It seems a bit unhelpful. But since I am used to peer reviewed journals I should be able to muck through the documentation.

Regards,

M

[Jeff Verdegan]

Melissa Nikolic wrote:
Thank you for your clear explanation. Frankly, telling a newbie to go to the Java documentation is like telling an introductory biology student to go find the answer to a question in a peer reviewed journal. It seems a bit unhelpful. But since I am used to peer reviewed journals I should be able to muck through the documentation.

Regards,

M

Well, it's just two different approaches. There's a continuum of how much direct help can be offered vs. just pointing someone in the right direction and letting them try to figure it out on their own, and, other than not handing over full code solutions, there are as many different opinions on what kind of help should be given as there are people giving help. For beginners, I usually just provide the JLS as additional information, since a lot of it can be difficult reading, even for those with more experience. I guess Campbell felt it was better for you to read the relevant section of the JLS first, and then ask more specific questions if they arise from there. Either way, we're all just trying to help you learn.

[Melissa Nikolic]

Jeff Verdegan wrote:

Melissa Nikolic wrote:
Thank you for your clear explanation. Frankly, telling a newbie to go to the Java documentation is like telling an introductory biology student to go find the answer to a question in a peer reviewed journal. It seems a bit unhelpful. But since I am used to peer reviewed journals I should be able to muck through the documentation.

Regards,

M

Well, it's just two different approaches. There's a continuum of how much direct help can be offered vs. just pointing someone in the right direction and letting them try to figure it out on their own, and, other than not handing over full code solutions, there are as many different opinions on what kind of help should be given as there are people giving help. For beginners, I usually just provide the JLS as additional information, since a lot of it can be difficult reading, even for those with more experience. I guess Campbell felt it was better for you to read the relevant section of the JLS first, and then ask more specific questions if they arise from there. Either way, we're all just trying to help you learn.

Yes, I can see the merit in your argument. I did go to the documentation suggested and I have another question. In "Narrowing Primitive Conversions" http://java.sun.com/docs/books/jls/second_edition/html/conversions.doc.html#25363 the documentation states the following:

The following 23 specific conversions on primitive types are called the narrowing primitive conversions:
byte to char
short to byte or char
char to byte or short
int to byte, short, or char
long to byte, short, char, or int
float to byte, short, char, int, or long
double to byte, short, char, int, long, or float

Everything makes sense to me but the narrowing of a byte to a char. Why would a narrowing conversion take place from a byte (8 bits) to a char (16 bits)? And why would you narrow the conversion from a byte to a char but not from a byte to a short (which has the same bit width as the char)?

Thanks for your help.

M

[Jeff Verdegan]

Melissa Nikolic wrote:I did go to the documentation suggested and I have another question. In "Narrowing Primitive Conversions" http://java.sun.com/docs/books/jls/second_edition/html/conversions.doc.html#25363 the documentation states the following:

The following 23 specific conversions on primitive types are called the narrowing primitive conversions:
byte to char
short to byte or char
char to byte or short
int to byte, short, or char
long to byte, short, char, or int
float to byte, short, char, int, or long
double to byte, short, char, int, long, or float

Everything makes sense to me but the narrowing of a byte to a char. Why would a narrowing conversion take place from a byte (8 bits) to a char (16 bits)? And why would you narrow the conversion from a byte to a char but not from a byte to a short (which has the same bit width as the char)?

Byte and short are both signed. Every value that can be represented by a byte can also be represented by a short.

Char is unsigned, so the values -128..-1 that can be represented in a byte cannot be represented in a short.

So even though it doesn't intuitively seem like "narrowing" in that short has more bits (i.e., is "wider") than byte, since there are values that byte can represent that short can't, it falls under narrowing conversions. That's also why both char ⇒ short and short ⇒ char are narrowing conversions. Even though both have the same number of bits, each can represent values that the other cannot.