java - 为什么JAVA 10中的var不能初始化为null？

Question

我正在研究 JAVA 10 中引入的新功能，在那里我发现了一个非常有趣的事实，即您不能用 null 声明变量。

只要你写下一段代码，

var a = null;

它抛出一个错误:

variable initializer is null

现在，众所周知，我们不能将基本类型声明为 null，因此下面的语句没有任何意义。

int a  = null;

这意味着，如果开发人员用 null 初始化一个 var，他肯定想在其中放入一个 Object，而不是文字 val。如果是这样的话，我的问题是

为什么编译器不认为它是一个 Object var 而是抛出错误。

另一方面，如果你写下面的语句，它工作得很好:

var a = (Object)null;

声明一个变量为null的原因是什么

考虑以下情况，我想初始化 var 并想在条件 block 之外使用它:

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

因此，在这种情况下，因为我们希望 a 的范围在条件 block 之外，所以我们需要在 if block 之外初始化它为 null，这使用 var 是不可能的。

Answer 1

编译器可以将(至少)三种可能的类型推断策略应用于var o = null:

• 选择 Void
• 选择对象
• 查找稍后的初始化并选择该类型

所有这些在技术上都是可行的，因此出现了一个问题，哪个对开发人员最有意义。

很明显，Void 没什么用，我认为 Object 也没有多大用处。虽然正确，但选择这两种类型中的任何一种都不太可能帮助开发人员编写更好、更易读的代码。

最后一个选项，寻找初始化，有意没有采用以避免所谓的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`

如果编译器为 parent 推断出 Node 因为 determineParent() 返回它，这将编译。但是代码很脆弱，因为对最后一行的更改可能会导致在第一行中选择不同的类型，从而在第二行中出现编译错误。那可不好!

我们已经习惯了更改类型的声明可能导致错误的事实，但这里的更改(第 3 行)、它的影响(第 1 行)和随之而来的错误(第 2 行)可能相距甚远，这使得开发人员理解或更好地预测会发生什么变得更加复杂。

通过保持类型推断规则简单，开发人员可以更轻松地为正在发生的事情形成一个简单但正确的心智模型。

附录

有人怀疑选项 3(从稍后的初始化中推断类型)在技术上是否确实可行。我的观点(确实如此)是基于我对 JEP 286 的理解，具体来说:

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.