Why var in JAVA 10 can not be initialized to null?

Question

I was playing around new features that have been introduced in JAVA 10, where in I found quite interesting fact that you can't declare a variable with null.

As soon as you write below piece of code,

var a = null;

It throws an error :

variable initializer is null

Now, as we all know that we can't declare a primitive type to null, so the below statement doesn't make any sense.

int a  = null;

That means, if a developer is initializing a var with null, it definitely wants to put an Object in it, instead of a literal val. If that's the case, my questions here is

Why doesn't compiler consider it to be an Object var and instead throws an error.

On the other hand, if you write below statement, it works perfectly fine :

var a = (Object)null;

What is the reason to declare a var with null

Consider below case where I want to initialize var and want to use it outside condition blocks:

var a = null;
if(some condition) Initialize with some arguments
else Initialize with some other arguments
//Use a variable here

So, in this case, as we want scope of a to be outside of conditional blocks we have a requirement to intialize it will null outside if block, which is not possible using var.

Answer 1

There are (at least) three possible type inference strategies the compiler could apply to var o = null:

• pick Void
• pick Object
• look for a later initialization and pick that type

All of them are technically feasible, so the question emerges, which one makes the most sense for developers.

Clearly, Void is pretty useless and I would argue that Object is not much more useful, either. While correct, picking either of these types is unlikely to help the developer write better and more readable code.

The last option, looking for an initialization, was not adopted on purpose to avoid so-called action-at-a-distance errors:

var parent = null;
// imagine some recursion or loop structure, so this makes more sense
processNode(parent); // expects a parameter of type `Node`
parent = determineParent(); // returns a parameter of type `Node`

If the compiler inferred Node for parent because determineParent() returns it, this would compile. But the code is fragile because changes to the last line, might lead to a different type chosen in the first line and hence to compile errors on the second line. That's not good!

We're used to the fact that changing a type's declaration can lead to errors down the road but here the change (line 3), its effect (line 1), and consequent error (line 2) can be pretty far apart, this making it much more complicated for developers to understand or, better, predict what happens.

By keeping the type inference rules simple, developers have it easier to form a simple but correct mental model of what's going on.

Addendum

There are doubts whether option 3, inferring the type from a later initialization, is indeed technically feasible. My opinion (that it is) is based on my understanding of JEP 286, specifically:

On the other hand, we could have expanded this feature to include the local equivalent of "blank" finals (i.e., not requiring an initializer, instead relying on definite assignment analysis.) We chose the restriction to "variables with initializers only" because it covers a significant fraction of the candidates while maintaining the simplicity of the feature and reducing "action at a distance" errors.

Similarly, we also could have taken all assignments into account when inferring the type, rather than just the initializer; while this would have further increased the percentage of locals that could exploit this feature, it would also increase the risk of "action at a distance" errors.

Answer 2

What I am asking how can we extend the scope in that case. So for example, if I want to initialize a variablee inside a condition block but want to expand the scope so that the same variable can be used outside the block, what can be done in case of var.

The answer is that you either use:

var a = (RealType) null;

or (to be sensible about it) you use a conventional typed declaration:

RealType a = null;

The var form is just a convenience to avoid having to write a specific type. It simply doesn't work when you initialize with null. Inferring Object as the type of a is not useful behavior in the vast majority of cases.

---

For example, if (hypothetically) a var could be assigned with a null:

    var a = null;            
    if (something) {
        a = someMethodReturningRealType();
    }
    a.someRealTypeMethod();  // Compilation error ... because the inferred
                             // type is java.lang.Object.  Oops!!

And this is the correct way to write the code:

    RealType a = null;       // Just use a classic variable declaration
    if (something) {
        a = someMethodReturningRealType();
    }
    a.someRealTypeMethod();

---

My example is just to share where all we may need to declare a var as null. And it seems there is no clear way to do that.

No. You do not need to do it. You want to do it ... but "want" and "need" are not the same thing.

Moreover, this is a very basic Question as if we can do Object x = null; why cant we can do var x = null;

Because the JLS forbids it. That's it. End of story.

If you don't like it, fine. But this is not a discussion forum. And we are not the people who need to be convinced anyway.

Answer 3

One could think the question isn't that far-fetched looking at the handling of genric types.

Let's examine it using List<T> list; as an example. If you do not specify the generic type (List list;) the compiler will handle it with the raw type. You can then add everything to the list - of course null. Applying the concepts of raw type and type erasure to var could allow you to declare var o; and assign later on everything to o. But since using the raw type is discouraged it is obvious that it wasn't choosen how var should work.

Regarding the case List<?> list; and applying it to var o = null; you could think of something like this: ? o. But this leads to nothing. In case of List<?> list; the only option that remains is add(null);. Following the theoretical example and trying to be consistent with present concepts this would mean ? o can only be initialized this way:? o = null;. So your intention to decalre a var and initialize it later would syntactically be possible, but symantically it makes no sense as it would be initialized always the same way with null. So it wouldn't provide any additional value but add complexity.

Answer 4

From an Oracle JDK 10 page:

you cannot just use the var syntax to declare a variable without a value You cannot initialise a var variable to null either. Indeed it is not clear what the type should be as it’s probably intended for late initialisation.

So basically, you have to be specific as to the datatype you want, the compiler cannot just assume you want Object or any other type.

So the following will all fail compilation:

var x;

var x = null;

var x = () -> {}

Answer 5

When you declare a variable with the keyword var, it's just a shortcut for writing. At the compilation, the keyword will be replace by the type of this variable. In order to know what is the type of the variable, the initialization must be explicit. If you initialise your variable with null, the compiler can't know what is the type of the variable and so can't replace var. So it's forbidden.

Answer 6

This is explicitly listed as an illegal initialization of a local variable in JLS Sec 14.4.1:

It is a compile-time error if T is the null type.

• ...
• var g = null; // Illegal: null type

Null is a type in Java:

There is also a special null type, the type of the expression null

However, it is impossible to declare a variable of this type (e.g. you couldn't write null g; or Null g; in a way that would refer to that type), and even if you could, the only possible value it could have would be null:

The null reference is the only possible value of an expression of null type.

So there's no point in allowing you to declare a variable of this type.

Answer 7

You cannot initialize a var variable to null. By assigning null, it is not clear what the type should be, since in Java, any object reference can be null. In the following example, because there is no predefined data type for a null value, the compiler is not able to interpret a type 'test', which would cause a complication error.

var test=null;

//Compilation error because compiler cannot infer type for local variable count since any Java object reference can be null

Answer 8

From the Java 10 Local Variable Type Inference page:

You cannot initialise a var variable to null either. Indeed it is not clear what the type should be as it’s probably intended for late initialisation.

|  Error:
|  cannot infer type for local variable x
|    (variable initializer is 'null')
|  var x = null;
|  ^-----------^

null is not a type, so the compiler can't infer the type of the RHS expression.

Answer 9

var is used as a lazy type. When you do var a = new Foo();, the compiler knows that a is of Foo type, this will enable you to call members of Foo using a at compile time.

var a = null; tells the compiler nothing. If the compiler treats a as Object class, then there is no purpose in using var type - you could have easily used Object a = null;.

Update

I think you are thinking this is working like the var in Javascript, which is absolutely wrong.

From one of your comments somewhere else:

What I am asking is at time of compilation, compiler can simply change the type to Object (Upcast) on the safer side and if in program , variable has been initialized by some specific class Object, then compiler can change it that specific type.

This clearly means that you are looking for a var capability that is just like what the Javascript is doing.

Why is it wrong in Java? Consider this:

var a = null; // Compiler makes 'a' an Object

if (checkSomething()) {
    a = new Foo(); // Compiler makes 'a' a Foo
}
else {
    a = new Bar(); // Compiler makes 'a' a Bar
}

test(a); // Should this be allowed???

public void test(Foo foo) {}

Should the compiler allow this? No. You will only know what type var is only at runtime. The compiler can never guess what this is at compile-time.

This is why var can never totally replace the traditional way of defining an explicit type. Always remember, var is just a syntactic sugar.