will not compile but --bW; will compile fine due to the presence of an implicit cast as explained before.
[HD Pg 129, Sec. 5.1.5 - numeric-promotion-and-primitive-wrapper-objects]
Moderator: admin
-
- Posts: 202
- Joined: Mon Apr 02, 2018 8:40 am
- Contact:
[HD Pg 129, Sec. 5.1.5 - numeric-promotion-and-primitive-wrapper-objects]
I don't know what is this referring to ?
-
- Site Admin
- Posts: 10065
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: [HD Pg 129, Sec. 5.1.5 - numeric-promotion-and-primitive-wrapper-objects]
Refers to the previous paragraph under title "Curious case of unary increment/decrement and compound assignment operators".
But I do think that this para should be improved.To put it simply, the rules of numeric promotion do not apply to ++, -- and the compound assignment operators such as +=, -=, and *=. Thus, the following statements will compile fine without any explicit cast.
...
Observe the statements b1 *= b2; and f += d;. They behave as if they are the short hand for b1 = (byte)(b1*b2); and f = (float)(f+d); In other words, the result of a compound assignment operation is implicitly cast back to the target type irrespective of the type of the second operand.
If you like our products and services, please help us by posting your review here.
-
- Posts: 202
- Joined: Mon Apr 02, 2018 8:40 am
- Contact:
Re: [HD Pg 129, Sec. 5.1.5 - numeric-promotion-and-primitive-wrapper-objects]
I don't understand why will not compile
What is the value of bw?
Code: Select all
Byte bW = 1; bW = -bw;
What is the value of bw?
-
- Site Admin
- Posts: 10065
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: [HD Pg 129, Sec. 5.1.5 - numeric-promotion-and-primitive-wrapper-objects]
oh, I see now. It should be bW (not bw). -bW will generate an int due to numeric promotion and so cannot be assigned back to bW because bW's type Byte. But --bW is fine.
If you like our products and services, please help us by posting your review here.
-
- Posts: 95
- Joined: Sat Dec 26, 2015 6:37 pm
- Contact:
Re: [HD Pg 129, Sec. 5.1.5 - numeric-promotion-and-primitive-wrapper-objects]
I follow
should be
However, I am failing to see the point of "final" (and unboxing?) in this example, since it produces the same error message without "final". I understand that the unary minus does not change the value of the variable itself anyway (so b1 is already final with respect to the unary minus operator anyway?). Also I understand that instead of what is there, if line 2 were "final Integer b2 = -b1;", then it would compile. Please help me to see the point of "The compiler doesn’t know that Byte is immutable" especially since "public final class Byte extends Number implements Comparable<Byte>"Thus, as far as the compiler is concerned, it is not sure that the result of -b1 will fit into a byte and so, it refuses to compile the code.
Also, likely related to my confusion,The rules differ a bit in case of final wrapper variables though. For example, the following code will not compile:This doesn’t work because b1 is a reference to an object. It is this reference that is final, not the contents of the object to which it points. The compiler doesn’t know that Byte is immutable. Thus, as far as the compiler is concerned, it is not sure that the result of -b1 will fit into a byte and so, it refuses to compile the code.Code: Select all
final Byte b1 = 10; Byte b2 = -b1; //will not compile even though b1 is final
The compiler doesn’t know that Byte is immutable.
should be
?The compiler doesn’t know that b1 is immutable.
-
- Site Admin
- Posts: 10065
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: [HD Pg 129, Sec. 5.1.5 - numeric-promotion-and-primitive-wrapper-objects]
A class being final doesn't mean it is immutable because final only means that a class cannot be extended, while immutable means that an object's member fields' value doesn't change once set. But yes, I am not sure what the author had in mind with that statement. Will check.
-Paul.
-Paul.
If you like our products and services, please help us by posting your review here.
-
- Posts: 95
- Joined: Sat Dec 26, 2015 6:37 pm
- Contact:
Re: [HD Pg 129, Sec. 5.1.5 - numeric-promotion-and-primitive-wrapper-objects]
Looking forward. Thanks.
-
- Site Admin
- Posts: 10065
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: [HD Pg 129, Sec. 5.1.5 - numeric-promotion-and-primitive-wrapper-objects]
Here is what it is trying to get at:
1. Byte is immutable, not because it is final but because the API says so. Compiler cannot determine that a Byte object is immutable just by looking at final modifer of Byte class declaration.
2. Therefore, compiler cannot know that after this statement: final Byte b1 = 10;, the value contained by the Byte object referred to by b1 will not change. (Because it is the reference b1 which is final, not the value contained in the Byte object referred to by b1, from the compiler's perspective.)
3. Therefore, when you do -b1, the compiler is not sure whether the value of -b1 will fit into a byte (even though we know that the value -10 is small enough to fit into a byte.).
That is the reason it refuses to compile the statement: Byte b2 = -b1;
The usage of final is highlighted here because the following works:
final byte b1 = 10;
byte b2 = -b1;
The distinction between the two is that in case of a primitive variable, the value is final, but in case of a reference variable, the reference is final, not the value contained in the object that the reference is pointing to.
1. Byte is immutable, not because it is final but because the API says so. Compiler cannot determine that a Byte object is immutable just by looking at final modifer of Byte class declaration.
2. Therefore, compiler cannot know that after this statement: final Byte b1 = 10;, the value contained by the Byte object referred to by b1 will not change. (Because it is the reference b1 which is final, not the value contained in the Byte object referred to by b1, from the compiler's perspective.)
3. Therefore, when you do -b1, the compiler is not sure whether the value of -b1 will fit into a byte (even though we know that the value -10 is small enough to fit into a byte.).
That is the reason it refuses to compile the statement: Byte b2 = -b1;
The usage of final is highlighted here because the following works:
final byte b1 = 10;
byte b2 = -b1;
The distinction between the two is that in case of a primitive variable, the value is final, but in case of a reference variable, the reference is final, not the value contained in the object that the reference is pointing to.
If you like our products and services, please help us by posting your review here.
-
- Posts: 95
- Joined: Sat Dec 26, 2015 6:37 pm
- Contact:
Re: [HD Pg 129, Sec. 5.1.5 - numeric-promotion-and-primitive-wrapper-objects]
So here is what I was going to say at first:
Just a thought ... since neither you nor I caught what the author intended at first glance, it is possible(?) that your following explanation may benefit some, if it were part of the regular text:Unfortunately, I am still failing to see the point of "final" and unboxing within the context of this example. As mentioned, it produces the same error message (error: incompatible types: int cannot be converted to Byte) without "final". It clearly refuses to compile the statement due to the rules of numeric promotion, which have nothing to due with final, objects, Wrapper, nor unboxing as my example proves:Code: Select all
byte b1 = 10; byte b2 = -b1;
Granted, the error message (error: incompatible types: possible lossy conversion from int to byte) is a liitle different, but it proves that maybe the example here could be a little better in tying in the aforementioned intended concepts? Please clear my confusion.
Thank you for tying this all together.The usage of final is highlighted here because the following works:
final byte b1 = 10;
byte b2 = -b1;
The distinction between the two is that in case of a primitive variable, the value is final, but in case of a reference variable, the reference is final, not the value contained in the object that the reference is pointing to.
-
- Site Admin
- Posts: 10065
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: [HD Pg 129, Sec. 5.1.5 - numeric-promotion-and-primitive-wrapper-objects]
Yes, that makes sense.
If you like our products and services, please help us by posting your review here.
Who is online
Users browsing this forum: No registered users and 105 guests