Primitive Conversion

[Vishal Gupta]

Source is here

Please see below code

  public class ShortInt {

		public static void main(String argv[]){

		//CASE 1	
		final int x = 10;
                                short y = x ;
		
		
		//CASE 2
		final int x2;
		x2 = 10;
		
		//short y2 = x2; // error type mismatch

		}
		
}  

I understand that here we don't need explicit narrowing conversion but why just changing the initialization in next line (Case 2), code is not able to compile. please explain

Thanks

[Rafael Angarita]

Edit: wrong explanation.

[Devaka Cooray]

Hello Vishal, It's a good question.

In the case-1 of your program, you are initializing the final variable 'x' with a value, in the same line of declaration. In this case, the compiler know that the value of this variable is definitely equals to 10, and it will never change (because x is a final variable). Hence, the compiler know that the value of 'x' is always within the range of the short primitive, and it can be assigned to any short variable without having any possible lose of precision.

But in the case-2, the initializing part is done separately, as another statement. In this case the compiler don't know what will be the value of this final variable at runtime. Think about it, even though *you* can see that the variable will 'x' is going to have the value of 10, the *compiler* couldn't see it. Unless in some special cases, the compilation process always flows line-by-line through the program. Therefore, only the programmer (you) and the runtime can understand the exact value of this final variable; but not the compiler. Therefore the compiler doesn't know whether the value of the variable x will be, or will not be within the range of the short primitive. That is why, it saying that there is a *possible* loss of precision.

Cheers,

Devaka.

[avi sinha]

awesome explanation sir & a very good question vishal.
i didn't know it can happen.

avi

[armando fonseca]

Rafael Angarita wrote:Hello Vishal,

When we are talking about primitives, implicit cast happens when you do a widening conversion. A narrowing conversion NEEDS a explicit cast, and you are trying to do a narrowing conversion without a cast.

Cheers

There s a special situation that you don't need explicit casting, here is:
Let say that here is the semantic of a variable: <target type> <variable name> = <source>;
1. When the source is a constant is an int, byte, short, char within in range of the target type.
2. When the target type is either byte, short or char.

- Armando

[Rafael Angarita]

Yeah very good. It totally confused me. ;)

[Vishal Gupta]

Thanks Devaka and others! I am elevated

Cheers

[Welly Tambunan]

armando fonseca wrote:

Rafael Angarita wrote:Hello Vishal,

When we are talking about primitives, implicit cast happens when you do a widening conversion. A narrowing conversion NEEDS a explicit cast, and you are trying to do a narrowing conversion without a cast.

Cheers

There s a special situation that you don't need explicit casting, here is:
Let say that here is the semantic of a variable: <target type> <variable name> = <source>;
1. When the source is a constant is an int, byte, short, char within in range of the target type.
2. When the target type is either byte, short or char.

- Armando

And i think when you return something from the method that's happen too. Isn't it?
Thanks for the link too Vishal.

[armando fonseca]

Welly Tambunan wrote:

armando fonseca wrote:

Rafael Angarita wrote:Hello Vishal,

When we are talking about primitives, implicit cast happens when you do a widening conversion. A narrowing conversion NEEDS a explicit cast, and you are trying to do a narrowing conversion without a cast.

Cheers

There s a special situation that you don't need explicit casting, here is:
Let say that here is the semantic of a variable: <target type> <variable name> = <source>;
1. When the source is a constant is an int, byte, short, char within in range of the target type.
2. When the target type is either byte, short or char.

- Armando

And i think when you return something from the method that's happen too. Isn't it?
Thanks for the link too Vishal.

Well, in that case is co-variant return if and only if the source is subtype of the target type, but that is objects type. On primitive implicit down casting is only achieve if and only if the two remarks from above are follow.

regards,
Armando

[Ruben Soto]

armando fonseca wrote:

Rafael Angarita wrote:Hello Vishal,

When we are talking about primitives, implicit cast happens when you do a widening conversion. A narrowing conversion NEEDS a explicit cast, and you are trying to do a narrowing conversion without a cast.

Cheers

There s a special situation that you don't need explicit casting, here is:
Let say that here is the semantic of a variable: <target type> <variable name> = <source>;
1. When the source is a constant is an int, byte, short, char within in range of the target type.
2. When the target type is either byte, short or char.

- Armando

You are correct about this, but you have to be very careful because this only happens during assignment conversion context. Basically, it will work when assigning a variable via explicit assignment like you mentioned, and also when returning a value from a method. But when you pass an argument to a method it doesn't take place (technically the matching of arguments to parameter variables during a method invocation is not an assignment conversion context.)
The JLS has all the details, but basically:

public class TypeConversion {
   static char method1() {
      final int i2 = 10;
      return i2; // OK
   }

   static void method2(char c2) {
   }

   public static void main(String[] args) {
      final int i1 = 10;
      char c1 = i1; // OK

      final int i3 = 10;
      method2(i3); // Compiler error
   }
}

[armando fonseca]

Ruben Soto wrote:

armando fonseca wrote:

Rafael Angarita wrote:Hello Vishal,

When we are talking about primitives, implicit cast happens when you do a widening conversion. A narrowing conversion NEEDS a explicit cast, and you are trying to do a narrowing conversion without a cast.

Cheers

There s a special situation that you don't need explicit casting, here is:
Let say that here is the semantic of a variable: <target type> <variable name> = <source>;
1. When the source is a constant is an int, byte, short, char within in range of the target type.
2. When the target type is either byte, short or char.

- Armando

You are correct about this, but you have to be very careful because this only happens during assignment conversion context. Basically, it will work when assigning a variable via explicit assignment like you mentioned, and also when returning a value from a method. But when you pass an argument to a method it doesn't take place (technically the matching of arguments to parameter variables during a method invocation is not an assignment conversion context.)
The JLS has all the details, but basically:

public class TypeConversion {
   static char method1() {
      final int i2 = 10;
      return i2; // OK
   }

   static void method2(char c2) {
   }

   public static void main(String[] args) {
      final int i1 = 10;
      char c1 = i1; // OK

      final int i3 = 10;
      method2(i3); // Compiler error
   }
}

Excellent point Ruben, thanks!

[Ruben Soto]

No problem, Armando. That is a tricky catch.

[Leonard Fischer]

I'm curious if there's a "reason" or "justification" for why assignment conversions are less restrictive than method conversions. Many of us have seen this 1000 times, but the "WHY" is bugging me. As Ruben points out, the following doesn't compile: final int i3 = 10; method2(i3); It seems strange to me that even the following doesn't compile: method2(10). The compiler should be able to recognize the constant 10!

[armando fonseca]

Leonard Fischer wrote:I'm curious if there's a "reason" or "justification" for why assignment conversions are less restrictive than method conversions. Many of us have seen this 1000 times, but the "WHY" is bugging me. As Ruben points out, the following doesn't compile: final int i3 = 10; method2(i3); It seems strange to me that even the following doesn't compile: method2(10). The compiler should be able to recognize the constant 10!

Leonard,
I will not be surprised if you score a 100 marks in your scjp. Your ability to observe those details are beneficial for this forum!

cheers!

[Ruben Soto]

Leonard Fischer wrote:I'm curious if there's a "reason" or "justification" for why assignment conversions are less restrictive than method conversions. Many of us have seen this 1000 times, but the "WHY" is bugging me. As Ruben points out, the following doesn't compile: final int i3 = 10; method2(i3); It seems strange to me that even the following doesn't compile: method2(10). The compiler should be able to recognize the constant 10!

I am not completely sure, but one thing that I can guess is that if you start allowing such conversions then you will have potential conflicts with overload resolution. But someone else might have a better reason why this is that way.