• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Local variables: type mismatch (int -> byte) if not initialized

 
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

trying out Inquisition, I came across the following problem:



Fact is that in line 4 there is a compile error "cannot convert from int to byte".
Same thing when I omit the final keyword in line 2.

Instead when I initialize the local variable i in line 2 (final int i = 127), it compiles fine.

Ok, I could learn this fact by heart, but as you know, there are tons of stuff to be learned by heart, so I strongly prefer a deep understanding of such "critical" behaviour.

Can anybody explain me WHY the later initialization doesn't work in this case?
What's going on behind the scenes? Why is the compiler so "stupid"? ;-)
Thanks in advance!
 
Ranch Hand
Posts: 446
1
Eclipse IDE MySQL Database Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
in java
implicitly everything lower than integer automatically gets converted into int and we cannot assign byte value to the int value
hence we have to do the explicit typecasting
we have to cast the int into byte as follows

This should work now
happy coding
 
Ulrich Vormbrock
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Prasad,

thank you for your reply - but sorry, this was not exactly the answer I'm looking for:
I already know that with such casting, I can "force" the compiler to trust me.

My question was related to the initialization stuff ... besides an int value of 127 (or generally spoken: from -128 until + 127) fits well into a byte ... same thing with a smart cowboy fitting into a pair of jeans ... a fat person - instead - should need a corset ... or simply a cast in order to wear them ;-)

So why do I need to initialize my int in the same line where I declare it?
 
Ranch Hand
Posts: 5575
Eclipse IDE Windows XP Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
https://coderanch.com/t/403360/Beginning-Java/java/final

specially look at the campbell answare
 
Ulrich Vormbrock
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Seetharaman Venkatasamy wrote:https://coderanch.com/t/403360/Beginning-Java/java/final

specially look at the campbell answare



Thanks a lot, Seetharaman!

I see, the main issue is the difference between compile-time and run-time constants.
Ok, I'll go more into the details, specially concerning the resulting byte-codes.

Sorry that I missed to perform a search before posting this problem!
 
Seetharaman Venkatasamy
Ranch Hand
Posts: 5575
Eclipse IDE Windows XP Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Ulrich Vormbrock wrote:Thanks a lot, Seetharaman!


You are welcome
 
Ulrich Vormbrock
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok, as proposed, I've just performed a generation of the following byte codes concerning compile-time and run-time constants:



... and now the run-time stuff:



If I'm right, the variable i2b (line 15, seems to be an alias for i, doesn't it?) is generated in the second byte code - so indeed there's no matter of initialization. Correct?
I've pasted thes two examples in order to become familiar with different behaviours behind the scenes.
 
Seetharaman Venkatasamy
Ranch Hand
Posts: 5575
Eclipse IDE Windows XP Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
or to better understand use a Java *decompiler*
 
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

I wrote a quick writeup about compile time constants a while ago. Maybe it can help here...

https://coderanch.com/t/454384/Beginning-Java/java/compile-time-constant

Henry
 
Ulrich Vormbrock
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the hint using a decompiler.
I've just tried out the cavaj decomplier in order to see how compile-time and run-time constants are treated differently.

Here are the results - first comes the compile-time stuff:


and then the run-time stuff:



Of cause I've been obliged to perform an explicit cast to byte (line 13) in the latter case ... otherwise my code should not have compiled (in order to decompile it again)

What I get from the latter case is the fact that "int i" is now a run-time constant (see line 12, last code).
In the first code, "int i" doesn't appear, instead "byte byte0" gets the value 127 (see line 12, first code).

Another nice thing to see (although it has nothing to do with this issue) is the fact that the compiler creates a default no-arg constructor!

It's a very good idea to study some pieces of code compiling and decompiling it again!
Maybe it's beyond the exam, but - as already mentioned - I want to become familiar with different behaviours of Java without having to learn tons of rules by heart.
 
Ranch Hand
Posts: 91
Notepad
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi
Take the modified code:

I think when final var is initialised on same line where it is declared JVM considered's it as compile time constant ,
else it is considerde as the declared primitive type.

Do not make thinks more complicated by decompiling and compiling it's easy.
 
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@Ulrich Vormbrock

Did you try inline initialization of the final int with value greater than 127?



 
Ulrich Vormbrock
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@Suresh Gokarakonda

Yes, I did ... as expected, the compiler jumps up and down, screaming "possible loss of precision" ... that's rather clear to me, because a number exceeding +27 is no longer considered as a byte.
 
Suresh Gokarakonda
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@Ulrich Vormbrock
Considering a scenario where the compiler allows what you were expecting, what might be the output of the below piece of code



1 int i = 1278;
2 byte b = i;
3 S.o.p(b);


In case the value of int i is less than 128 and works for your piece of code in the question, how will you enforce that the value is not changed by any other module.
If that gets changed the output of some part of your code would be unpredictable which might lead to a test scenario with random result.
 
Ulrich Vormbrock
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you, Suresh!

I see one crucial point concerning compile-time constants: to prevent them of being modified later by a routine or module.
Now it's perfectly clear to me - same thing with case-statements (switch-case) where only compile-time constants are allowed, too.
I revise my statement concerning compiler and "stupid behaviour" ;-)
 
Ranch Hand
Posts: 623
1
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Guys, I know this topic is kinda dead for 4 months, but let me ask, why this:



works fine, as the a is a compile-time constant, while this:



shows "Type mismatch: cannot convert from long to int" error in line 02. Isn't it the same situation as in the int/byte example - a compile-time constant that fits the int? Am I missing some obvious fact here?
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic