Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Char compiler error question

 
Oceana Wickramasinghe
Ranch Hand
Posts: 77
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can someone explains to me why this doesnt generate a compiler error



When this does



Error:possible loss of precision

Isnt c holding a char in the first program ?
 
Stephan van Hulst
Bartender
Pie
Posts: 5553
53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In the first program, you're assigning a compile time constant to the byte variable. The compiler can determine that the integral value for 'a' can fit inside a byte. In the second program, the compiler can't do this because a char variable can hold all sorts of values, including values that can't be represented by a byte.
 
Nitin Surana
Ranch Hand
Posts: 129
Java Netbeans IDE Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
char is 16-bits in java. So second program gives error.

While with the first one, as explained by Stephan is a runtime constant whose value can be stored within a char.
 
Stephan van Hulst
Bartender
Pie
Posts: 5553
53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Did you mean "compile time constant which can be stored within a byte"?
 
Oceana Wickramasinghe
Ranch Hand
Posts: 77
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

But its not declared static final is it, can you please explain why the compiler treats it as a constant even when its not declared static final?
 
Devaka Cooray
ExamLab Creator
Marshal
Pie
Posts: 4313
233
Chrome Eclipse IDE Google App Engine IntelliJ IDE jQuery Postgres Database Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Oceana Wickramasinghe wrote:But its not declared static final

Of course - that "byte c" is a variable - not a constant. But what you are assigning (the value 'c') is a constant at the run time.
 
Oceana Wickramasinghe
Ranch Hand
Posts: 77
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Devaka Cooray wrote:
Oceana Wickramasinghe wrote:But its not declared static final

Of course - that "byte c" is a variable - not a constant. But what you are assigning (the value 'c') is a constant at the run time.


But why? Can you please explain to me how it can be a compile time constant even when its not declared static final. Is it because in the second program i could change the value of the char later, and not in the first one?
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Oceana Wickramasinghe wrote:
Devaka Cooray wrote:
Oceana Wickramasinghe wrote:But its not declared static final

Of course - that "byte c" is a variable - not a constant. But what you are assigning (the value 'c') is a constant at the run time.


But why? Can you please explain to me how it can be a compile time constant even when its not declared static final. Is it because in the second program i could change the value of the char later, and not in the first one?


Because 'a', like all literals, such as 1, 2.3, "xyz", false, and Foo.class, is a constant that is known at compile-time. The compiler knows what the value of 'a' is and knows it can fit in a byte.

On the other hand, when you do

the compiler doesn't know the value of b. All it knows is that it's a char, and so therefore it might not fit in a byte.
 
Oceana Wickramasinghe
Ranch Hand
Posts: 77
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeff Verdegan wrote:
Oceana Wickramasinghe wrote:
Devaka Cooray wrote:
Oceana Wickramasinghe wrote:But its not declared static final

Of course - that "byte c" is a variable - not a constant. But what you are assigning (the value 'c') is a constant at the run time.


But why? Can you please explain to me how it can be a compile time constant even when its not declared static final. Is it because in the second program i could change the value of the char later, and not in the first one?


Because 'a', like all literals, such as 1, 2.3, "xyz", false, and Foo.class, is a constant that is known at compile-time. The compiler knows what the value of 'a' is and knows it can fit in a byte.

On the other hand, when you do

the compiler doesn't know the value of b. All it knows is that it's a char, and so therefore it might not fit in a byte.


Okey, so in your program, when compiler is on line it is aware that the value of b is 'a', correct? but when its on line 2, it loses that information, and only knows that b is a char? If that is correct, why does the compiler lose information like that, does the compiler loses information about the previous line when it executes a new one?
 
Henry Wong
author
Marshal
Pie
Posts: 20995
76
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Oceana Wickramasinghe wrote:Okey, so in your program, when compiler is on line it is aware that the value of b is 'a', correct? but when its on line 2, it loses that information, and only knows that b is a char? If that is correct, why does the compiler lose information like that, does the compiler loses information about the previous line when it executes a new one?


"Why does the compiler" do anything is determined by the Java Language Specification. This is true on how it behaves with compile time constants. Anyway, I did a writeup about this on the the ranch a while back...

http://www.coderanch.com/t/454384/java/java/compile-time-constant

Henry
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Oceana Wickramasinghe wrote:
Jeff Verdegan wrote:
Oceana Wickramasinghe wrote:
Devaka Cooray wrote:
Oceana Wickramasinghe wrote:But its not declared static final

Of course - that "byte c" is a variable - not a constant. But what you are assigning (the value 'c') is a constant at the run time.


But why? Can you please explain to me how it can be a compile time constant even when its not declared static final. Is it because in the second program i could change the value of the char later, and not in the first one?


Because 'a', like all literals, such as 1, 2.3, "xyz", false, and Foo.class, is a constant that is known at compile-time. The compiler knows what the value of 'a' is and knows it can fit in a byte.

On the other hand, when you do

the compiler doesn't know the value of b. All it knows is that it's a char, and so therefore it might not fit in a byte.


Okey, so in your program, when compiler is on line it is aware that the value of b is 'a', correct? but when its on line 2, it loses that information, and only knows that b is a char?


Correct.

Now, if b were declared final, then line 2 would compile, because b would be a compile-time constant, and the compiler would know that its value--'a'--fits into a byte.

If that is correct, why does the compiler lose information like that


Because that's what the JLS says it must do. And to answer your question of why the JLS was written that way, I wasn't there, and I'm not a language creator or compiler writer, but I can speculate that it's because it keeps things more consistent, which makes them much simpler. This is a special case, and it would be possible for the language to specify that the compiler should know that line 2 will succeed. But this special case fits into a whole family of structurally similar cases where it's impossible for the compiler to know. So, to keep the language definition simpler, the compiler doesn't know. This means compilers are easier to write and less buggy. It also means the language rules are easier for programmers to remember.

, does the compiler loses information about the previous line when it executes a new one?


The compiler doesn't execute your code. It just translates it. But, yes, except for a handful of very obvious, simple special cases--that is, compile-time constants--the compiler doesn't know what the result of executing a line of code will be.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic