implicit casting of final variables

[Jared Cope]

Hi,

I've come across this particularly evil example of code:

class MyClass
{
  public static void main(String []args)
  {
   final int i = 100;
   byte b = i;
   System.out.println(b);
  }
}

So what will happen here? We all know that an int can't be assigned to a byte without an explicit cast, so obviously the code won't compile. However, to my surprise it does! However, if you take out the final modifier for the i variable, the code won't compile. Moreover, if i gets assigned 200 (something larger than the range of a byte) and is final then it won't compile.

I'm just wondering what is happening behind the scenes. Is the compiler reclassifying i as a byte variable since it knows the value at compile time and knows that it can't change during runtime with the final modifier?

[chowdary Thammineedi]

Hi Jared

The compiler will automatically narrow down the assignment.
Dan Chisholm on his website explains this very well. Visit his site and your doubt's about automatic conversions will be DONE forever.

The rule is that in an assignment statement if the right hand side of the assignment is a COMPILE TIME CONSTANT of type byte,char,shot or int then it will be automatically converted(narrowed) to the reference type of the left hand side.

Chowdary

[kapil munjal]

Hi,

I think, COMPILE TIME CONSTANTS means final variables.

well, I think I am right about this, but if I am wrong then please correct me.

Thanks
Kaps

[Akshatha Nayak]

r final variables the only COMPILER TIME CONSTANT.. ??

[Stefan Guilhen]

No. Not only final variables are compiler time constants. You can express a compiler time constant as a literal too. For example:

   int i = some_value;
   final int x = 2;
   switch(i) {
      case 1: System.out.print("I is 1");break;
      case x: System.out.print("I is 2");break;
   }

Both case clauses are valid, because the arguments are compiler time constants, one represented by a literal and one by a final variable. Notice that the following does not compile:

   int amethod() { return 2;}
   
   void anotherMethod(int i) {
      final int x = amethod();
      switch(i) {
         case x: System.out.print("Inside case"); break;
      }
   }

The preceding code does not compile, because althoght x is a final variable it is not a compiler time constant, since its value will only be determined at runtime when the method amethod is invoked.

Hope that helps.

[Robert Chisholm]

As a corollary to the above post, this won't compile either. Although it's a bit off-topic, I notice it in a few mock exams.

 
public class Blah
{
    public static void aMethod(int a) 
    {
        System.out.println(a);
    }
 
    public static void main(String[] args)
    {
        final float f = 0;
        aMethod(f);     //No implicit narrowing cast to int
        aMethod(0.0f);  //No implicit narrowing cast to int
    }
} 

[kapil munjal]

Hi Robert,

could you tell me why there will be no implicit narrowing cast to int in your example.

Please explain this concept.

Thanks
Kaps

[Stefan Guilhen]

The rules for variable assignments do not apply to arguments passed to methods. I can remember that Dan's mock has an explanation about this... it seem the developers of Java chose not to perform an implicit cast in values passed as arguments because it would be dificult to determine which method should be called in case of overloading. Imagine this scenario:

void amethod(int a) { //Does something with an int}
void amethod(long a) { //Does something with a long}
 
void anotherMethod() {
   final long x = 10;
   amethod(x); // which one should be called in case of implicit cast?
}

As you can see, problems may arise here if the implicit casting is performed in arguments to methos. The value of x fits in an int, but its type is a long.... what should the compiler do to determine the method the programmer wants to be called?

Stefan.
[ August 20, 2004: Message edited by: Stefan Guilhen ]