本地类型推理与实例

Question

我试图扫描JEP-286关于局部类型推断的信息。我看到这只适用于局部变量-理解。因此，这确实有效：

public class TestClass {
    public static void main(String [] args){
        var list = new ArrayList<>();
        list.add("1");
        System.out.println(list.get(0)); // 1
    }  
}

另一方面，我确实看到这并不能编译：

public class TestClass {
    public var list = new ArrayList<>();
    public static void main(String [] args){

    }
}

很明显，事实并非如此，因为JEP是这么说的。现在我的问题是:

声明为var的公共/受保护成员失败是完全合理的，至少IMO是如此。但是，为什么即使它是私有，它也不能编译呢？我只能假设您仍然可以通过反射来获取该变量（我无法获取这样的局部字段）……而获取该变量需要进行转换，很可能是非常混乱的转换。

Answer 1

这并不是完全不可能将这些变量转换为可以通过反射进行检查的字段。E、 你可以做到

var l = new ArrayList<String>();
l.add("text");
System.out.println(l);
System.out.println(
  new Object(){ { var x = l; } }.getClass().getDeclaredFields()[0].getGenericType()
);

在当前版本中，它只打印 ArrayList，因此实际的泛型类型尚未存储在匿名内部类的类文件中，并且不太可能更改，因为支持此自省不是实际目标。这也只是一个特例，该类型像 ArrayList 一样表示

var acs = true? new StringBuilder(): CharBuffer.allocate(10);
acs.append("text");
acs.subSequence(1, 2);
System.out.println(
  new Object(){ { var x = acs; } }.getClass().getDeclaredFields()[0].getGenericType()
);

＜code＞acs＜/code＞的类型是＜code＞Appendable＜/code＞和＜code＞CharSequence＜/code>的交集类型，如通过调用其中任一接口的方法所示，但由于未指定编译器是否推断＜code＞#1扩展了Appendable

我不认为这是合成字段的问题，但对于显式声明的字段，它可能是问题。

然而，我怀疑专家组是否详细考虑了这些影响。相反，从一开始就决定不支持字段声明（从而跳过对含义的冗长思考），因为局部变量始终是该特性的目标。局部变量的数量远高于字段声明的数量，因此减少局部变量声明的样板会产生最大的影响。

Answer 2

各种原因:

>

可见性和类型是正交的-一个不应该影响另一个。如果可以使用var初始化私有变量，那么在使它们受保护或公开时必须更改它。

由于 var 使用右侧来推断类型，因此此类私有字段始终需要立即初始化。如果将初始化移动到构造函数中，则必须使类型显式。

使用< code>var,编译器可以推断出当前无法用Java表达的类型(例如,< code>Comparable

Answer 3

禁止字段和方法返回的类型推断的动机是API应该是稳定的；字段访问和方法调用在运行时通过描述符进行链接，因此，如果对实现的更改导致推断类型发生更改（模擦除），那么对推断类型进行细微更改的事情可能会导致现有编译客户端以可怕的方式中断。因此，将此用于实现，而不是用于API，是一个明智的指导原则。

有理由问“那么，私人领域和方法如何？”事实上，我们完全可以选择这样做。与所有设计决策一样，这是一种权衡；这将使推理能够在更多的地方使用，以换取用户模型中的更复杂。（我不太关心规范或编译器的复杂性；这是我们的问题。）比起添加各种周转考虑因素，比如“但是，如果字段和方法是私有的，那么它们是可以的”，更容易推理“对局部变量的推断是肯定的，字段和方法不是”。画出我们所做的这条线还意味着，将字段或方法从私有更改为非私有的兼容性结果不会与推断发生意外交互。

所以简短的回答是，这样做使语言更简单，而不会使特性的有用性大大降低。