Why does the Java compiler not understand this variable is always initialized?

class Foo{
	public static void main(String args[]){
		final int x=101;
				
		int y;
		if(x>100){
			y=-1;
		}
		System.out.println(y);
	}
}

Java compiler understands the condition of the if statement is always true and therefore y will always be initialized. No compile error, as expected.

class Bar{
	public static void main(String args[]){
		final int x;
        x=101;

		int y;		
		if(x>100){
			y=-1;
		}
		System.out.println(y);
	}
}

But when I break the declaration and initialization of x into two lines, the compiler does not seem to get that the condition is always true and y will always be initialized.

final int x;
x=101;
byte b;
b=x;
System.out.println(b);

Same thing happens here and the compiler gives a loss of precision error.

final int x=101;
byte b;
b=x;
System.out.println(b);

Again, the compiler can understand that x is inside the range of b.

As part of aiming for portability, there is a very specific set of rules for what a compiler should accept and what it should reject. Those rules both permit and require only a limited form of flow analysis when determining whether a variable is definitely assigned at its use.

See the Java Language Specification Chapter 16. Definite Assignment

The critical rule is the one in 16.2.7. if Statements, "if (e) S" case. The rule for being definitely assigned expands to:

V is assigned after if (e) S if, and only if, V is assigned after S and V is assigned after e when false.

y is the relevant V. It is unassigned before the if statement. It is indeed assigned after S, y = {y=-1;} but there is nothing making it assigned when x>100 is false.

Thus y is not definitely assigned after the if statement.

A more complete flow analysis would determine that the condition x>100 is always true, but the compiler is required by the JLS to reject the program based on these specific rules.

The final variable is fine. The rule is actually: -

> "It is a compile-time error if a final variable is assigned to unless > it is definitely unassigned (§16) immediately prior to the > assignment."

The declaration leaves it definitely unassigned, and even the limited flow analysis can determine that x is still definitely unassigned at the assignment.

It has to do with how the compiler determines if a statement will be executed or not. It is defined in the JLS #16:

> Each local variable and every blank final field must have a definitely assigned value when any access of its value occurs.

In your case, the compiler can't determine that y has been definitely assigned and gives you an error. This is because it would need to determine that the condition is always true and that is only possible if the condition in the if is a constant expression.

JLS #15.28 defines constant expressions:

>A compile-time constant expression is an expression denoting a value of primitive type or a String that does not complete abruptly and is composed using only the following: > > - [...]
> - Simple names (§6.5.6.1) that refer to constant variables (§4.12.4).

The JLS #4.12.4 defines constants variables as:

> A variable of primitive type or type String, that is final and initialized with a compile-time constant expression, is called a constant variable.

In your case, final int x = 101; is a constant variable but final int x; x = 101; is not.

What have you done for the variable x in the second code is called blank final variable. If a final variable is not initialized when it is declared, then it is known as a blank final variable.

Many Java developers think that value of a final variable is known in the compile time. This is NOT always true. It is said that value of a blank final variable NOT known at the compile time. Hence your second code will give you a compile error. Compiler can see that you have initialized the final variable x, but compile doesn't know it's value. So compiler can't resolve the if statement. Therefor it thinks that variable y is not initialized.

You can read more about Java final variables here.