Java 10 局部变量类型推断浅析

2023-08-21 16:39:05 190

前言

java10引进一种新的闪闪发光的特性叫做局部变量类型推断。听起来很高大上吧？它是什么呢?下面的两个情景是我们作为Java开发者认为Java比较难使用的地方。

上下文：陈词滥调和代码可读性

也许日复一日，你希望不再需要重复做一些事情。例如在下面的代码（使用Java9的集合工厂），左边的类型也许会感觉到冗余和平淡。

importstaticjava.util.Map.entry;
Listcities=List.of("Brussels","Cardiff","Cambridge")
MapcitiesPopulation
=Map.ofEntries(entry("Brussels",1_139_000),
entry("Cardiff",341_000));

这是一个非常简单的例子，不过它也印证了传统的Java哲学：你需要为所有包含的简单表达式定义静态类型。再让我们来看看有一些复杂的例子。举例来说，下面的代码建立了一个从字符串到词的柱状图。它使用groupingBy收集器将流聚合进Map。groupingBy收集器还可以以一个分类函数为第一个参数建立映射的键和第二个收集器的(counting())键计算关联的数量。下面就是例子：

Stringsentence="AsimpleJavaexamplethatexploreswhatJava
10hastooffer";
Collector>byOccurrence
=groupingBy(Function.identity(),counting());
MapwordFrequency
=Arrays.stream(sentence.split(""))
.collect(byOccurrence);

复杂表达式提取到一个变量或方法来提升代码的可读性和重用性，这是非常有意义的。在这里例子中，建立柱状图的逻辑使用了收集器。不幸地是，来自groupingBy的结果类型几乎是不可读的！对于这一点你毫无办法，你能做的只有观察。

最重要的一点是当Java中增加新的类库的时候，他们开发越来越多的泛型，这就为开发者引进了更多的公式化代码（boilerplatecode），从而带来了额外的压力。上面的例子并不是说明了编写类型就不好。很明显，强制将为变量和方法签名定义类型的操作执行为一种需要被尊重的协议，将有益于维护和理解。然而，为中间表达式声明类型也许会显得无用和冗余。

类型推断的历史

我们已经在Java历史上多次看到语言设计者添加“类型推断”来帮助我们编写更简洁的代码。类型推断是一种思想：编译器可以帮你推出静态类型，你不必自己指定它们。

最早从Java5开始就引入了泛型方法，而泛型方法的参数可以通过上下文推导出来。比如

这段代码：

Listcs=Collections.emptyList();

可以简化成：

Listcs=Collections.emptyList();

然后，在Java7中，可以在表达式中省略类型参数，只要这些参数能通过上下文确定。比如：

Map>myMap=newHashMap>();

可以使用尖括号<>运算符简化成：

Map>userChannels=newHashMap<>();

一般来说，编译器可以根据周围的上下文来推断类型。在这个示例中，从左侧可以推断出HashMap包含字符串列表。

从Java8开始，像下面这样的Lambda表达式

PredicatenameValidation=(Stringx)->x.length()>0;

可以省略类型，写成

PredicatenameValidation=x->x.length()>0;

局部变量类型推断

随着类型越来越多，泛型参数有可能是另一个泛型，这种情况下类型推导可以增强可读性。Scala和C#语言允许将局部变量的类型声明为var，由编译器根据初始化语句来填补合适的类型。比如，前面对userChannels的声明可以写成这样：

varuserChannels=newHashMap>();

也可以是根据方法的返回值（这里返回列表）来推断：

varchannels=lookupUserChannels("Tom");
channels.forEach(System.out::println);

这种思想称为局部变量类型推断，它已经在Java10中引入！

例如下面的代码：

Pathpath=Paths.get("src/web.log");
try(Streamlines=Files.lines(path)){
longwarningCount
=lines
.filter(line->line.contains("WARNING"))
.count();
System.out.println("Found"+warningCount+"warningsinthe
logfile");
}catch(IOExceptione){
e.printStackTrace();
}

在Java10中可以重构成这样：

varpath=Paths.get("src/web.log");
try(varlines=Files.lines(path)){
varwarningCount
=lines
.filter(line->line.contains("WARNING"))
.count();
System.out.println("Found"+warningCount+"warningsinthe
logfile");
}catch(IOExceptione){
e.printStackTrace();
}

上述代码中的每个表达式仍然是静态类型（即值的类型）：

局部变量path的类型是Path
变量lines的类型是Stream
变量warningCount的类型是long

也就是说，如果给这些变量赋予不同值则会失败。比如，像下面这样的二次赋值会造成编译错误：

varwarningCount=5;
warningCount="6";
|Error:
|incompatibletypes:java.lang.Stringcannotbeconvertedtoint
|warningCount="6"

然而还有一些关于类型推断的小问题；如果类Car和Bike都是Vehicle的子类，然后声明

varv=newCar();

这里声明的v的类型是Car还是Vehicle？这种情况下很好解释，因为初始化器（这里是Car）的类型非常明确。如果没有初始化器，就不能使用var。稍后像这样赋值

v=newBike();

会出错。换句话说，var并不能完美地应用于多态代码。

那应该在哪里使用局部变量类型推断呢？

什么情况下局部类型推断会失效？你不能在字段和方法签名中使用它。它只能用于局部变量，比如下面的代码是不正确的：

publiclongprocess(varlist){}

不能在不明确初始化变量的情况下使用var声明局部变量。也就是说，不能使用var语法声明一个没有赋值的变量。下面这段代码

varx;

这会产生编译错误：

|Error:
|cannotinfertypeforlocalvariablex
|(cannotuse'var'onvariablewithoutinitializer)
|varx;
|^----^

也不能把var声明的变量初始化为null。实事上，在后期初始化之前它究竟是什么类型，这并不清楚。

|Error:
|cannotinfertypeforlocalvariablex
|(variableinitializeris'null')
|varx=null;
|^-----------^

不能在Lambda表达式中使用var，因为它需要明确的目标类型。下面的赋值就是错的：

varx=()->{}
|Error:
|cannotinfertypeforlocalvariablex
|(lambdaexpressionneedsanexplicittarget-type)
|varx=()->{};
|^---------------^

但是，下面的赋值却是有效的，原因是等式右边确实有一个明确的初始化。

varlist=newArrayList<>();

这个列表的静态类型是什么？变量的类型被推导为ArrayList

Java 10 局部变量类型推断浅析

热门推荐

随机推荐