initialization - What happens to a declared, uninitialized variable in Java?

Question

Does it have a value?

I am trying to understand what is the state of a declared but not-initialized variable/object in Java.

I cannot actually test it, because I keep getting the "Not Initialized" compile-error and I cannot seem to be able to suppress it.

Though for example, I would guess that if the variable would be an integer it could be equal to 0.

But what if the variable would be a String, would be it be equal to null or the isEmpty() would return true?

Is the value the same for all non-initialized variables? or every declaration (meaning, int, string, double etc) has a different value when not explicitly initialized?

---

UPDATE

So as I see now, it makes a big difference if the variable is declared locally or in the Class, though I seem to be unable to understand why when declaring as static in the class it gives no error, but when declaring in the main it produces the "Not Initialized" error.

Answer 1

How exactly a JVM does this is entirely up to the JVM and shouldn't matter for a programmer, since the compiler ensures that you do not read uninitialized local variables.

Fields however are different. They need not be assigned before reading them (unless they are final) and the value of a field that has not been assigned is null for reference types or the 0 value of the appropriate primitive type, if the field has a primitive type.

Using s.isEmpty() for a field String s; that has not been assigned results in a NullPointerException.

---

So as I see now, it makes a big difference if the variable is declared locally or in the Class, though I seem to be unable to understand why when declaring in the class it gives no error, but when declaring in the main it produces the "Not Initialized" error.

In general it's undesirable to work with values that do not have a value. For this reason the language designers had 2 choices:

a) define a default value for variables not yet initialized
b) prevent the programmers from accessing the variable before writing to them.

b) is hard to achieve for fields and therefore option a) was chosen for fields. (There could be multiple methods reading/writing that could be valid or invalid depending on the order of calls, which could only be determined at runtime).

For local variables option b) is viable, since all possible paths of the execution of the method can be checked for assignment statements. This option was chosen during the language design for local variables, since it can help to find many easy mistakes.