【编者按】本文作者为专注于自然语言处理多年的 Pierre-Yves Saumont,Pierre-Yves 著有30多本主讲 Java 软件开发的书籍,自2008开始供职于 Alcatel-Lucent 公司,担任软件研发工程师。
本文主要介绍了 Java 8 中的函数与原语,由国内 ITOM 管理平台 OneAPM 编译呈现。
Tony Hoare 把空引用的发明称为“亿万美元的错误”。也许在 Java 中使用原语可以被称为“百万美元的错误”。创造原语的原因只有一个:性能。原语与对象语言毫无关系。引入自动装箱和拆箱是件好事,不过还有很多有待发展。可能以后会实现(据说已经列入 Java 10的发展蓝图)。与此同时,我们需要对付原语,这可是个麻烦,尤其是在使用函数的时候。
Java 5/6/7的函数
在 Java 8之前,使用者可以创建下面这样的函数:
public interface Function<T, U> {
U apply(T t);
}
Function<Integer, Integer> addTax = new Function<Integer, Integer>() {
@Override
public Integer apply(Integer x) {
return x / 100 * (100 + 10); }
};
System.out.println(addTax.apply(100));
这些代码会产生以下结果:
110
Java 8 带来了 Function<T, U>
接口和 lambda 语法。我们不再需要界定自己的功能接口, 而且可以使用下面这样的语法:
Function<Integer, Integer> addTax = x -> x / 100 * (100 + 10);
System.out.println(addTax.apply(100));
注意在第一个例子中,笔者用了一个匿名类文件来创建一个命名函数。在第二个例子中,使用 lambda 语法对结果并没有任何影响。依然存在匿名类文件, 和一个命名函数。
一个有意思的问题是:“x
是什么类型?”第一个例子中的类型很明显。可以根据函数类型推断出来。Java 知道函数参数类型是 Integer,因为函数类型明显是Function<Integer, Integer>
。第一个 Integer
是参数的类型,第二个 Integer
是返回类型。
装箱被自动用于按照需要将 int
和 Integer
来回转换。下文会详谈这一点。
可以使用匿名函数吗?可以,不过类型就会有问题。这样行不通:
System.out.println((x -> x / 100 * (100 + 10)).apply(100));
这意味着我们无法用标识符的值来替代标识符 addTax
本身( addTax
函数)。在本案例中,需要恢复现在缺失的类型信息,因为 Java 8 无法推断类型。
最明显缺乏类型的就是标识符 x
。可以做以下尝试:
System.out.println((Integer x) -> x / 100 * 100 + 10).apply(100));
毕竟在第一个例子中,本可以这样写:
Function<Integer, Integer> addTax = (Integer x) -> x / 100 * 100 + 10;
这样应该足够让 Java 推测类型,但是却没有成功。需要做的是明确函数的类型。明确函数参数的类型并不够,即使已经明确了返回类型。这么做还有一个很严肃的原因:Java 8对函数一无所知。可以说函数就是普通对象加上普通方法,仅此而已。因此需要像下面这样明确类型:
System.out.println(((Function<Integer, Integer>) x -> x / 100 * 100 + 10).apply(100));
否则,就会被解读为:
System.out.println(((Whatever<Integer, Integer>) x -> x / 100 * 100 + 10).whatever(100));
因此 lambda 只是在语法上起到简化匿名类在 Function
(或 Whatever
)接口执行的作用。它实际上跟函数毫不相关。
假设 Java 只有 apply
方法的 Function
接口,这就不是个大问题。但是原语怎么办呢?如果 Java 只是对象语言,Function
接口就没关系。可是它不是。它只是模糊地面向对象的使用(因此被称为面向对象)。Java 中最重要的类别是原语,而原语与面向对象编程融合得并不好。
Java 5 中引入了自动装箱,来协助解决这个问题,但是自动装箱对性能产生了严重限制,这还关系到 Java 如何求值。Java 是一种严格的语言,遵循立即求值规则。结果就是每次有原语需要对象,都必须将原语装箱。每次有对象需要原语,都必须将对象拆箱。如果依赖自动装箱和拆箱,可能会产生多次装箱和拆箱的大量开销。
其他语言解决这个问题的方法有所不同,只允许对象,在后台解决了转化问题。他们可能会有“值类”,也就是受到原语支持的对象。在这种功能下,程序员只使用对象,编译器只使用原语(描述过于简化,不过反映了基本原则)。Java 允许程序员直接控制原语,这就增大了问题难度,带来了更多安全隐患,因为程序员被鼓励将原语用作业务类型,这在面向对象编程或函数式程序设计中都没有意义。(笔者将在另一篇文章中再谈这个问题。)
不客气地说,我们不应该担心装箱和拆箱的开销。如果带有这种特性的 Java 程序运行过慢,这种编程语言就应该进行修复。我们不应该试图用糟糕的编程技巧来解决语言本身的不足。使用原语会让这种语言与我们作对,而不是为我们所用。如果问题不能通过修复语言来解决,那我们就应该换一种编程语言。不过也许不能这样做,原因有很多,其中最重要的一条是只有 Java 付钱让我们编程,其他语言都没有。结果就是我们不是在解决业务问题,而是在解决 Java 的问题。使用原语正是 Java 的问题,而且问题还不小。
现在不用对象,用原语来重写例子。选取的函数采用类型 Integer
的参数,返回Integer
。要取代这些,Java 有 IntUnaryOperator
类型。哇哦,这里不对劲儿!你猜怎么着,定义如下:
public interface IntUnaryOperator {
int applyAsInt(int operand);
...
}
这个问题太简单,不值得调出方法 apply
。
因此,使用原语重写例子如下:
IntUnaryOperator addTax = x -> x / 100 * (100 + 10);
System.out.println(addTax.applyAsInt(100));
或者采用匿名函数:
System.out.println(((IntUnaryOperator) x -> x / 100 * (100 + 10)).applyAsInt(100));
如果只是为了 int
返回 int
的函数,很容易实现。不过实际问题要更加复杂。Java 8 的 java.util.function
包中有43种(功能)接口。实际上,它们不全都代表功能,可以分类如下:
- 21个带有一个参数的函数,其中2个为对象返回对象的函数,19个为各种类型的对象到原语或原语到对象函数。2个对象到对象函数中的1个用于参数和返回值属于相同类型的特殊情况。
- 9个带有2个参数的函数,其中2个为(对象,对象)到对象,7个为各种类型的(对象,对象)到原语或(原语,原语)到原语。
- 7个为效果,非函数,因为它们并不返回任何值,而且只被用于获取副作用。(把这些称为“功能接口”有些奇怪。)
- 5个为“供应商”,意思就是这些函数不带参数,却会返回值。这些可以是函数。在函数世界里,有些特殊函数被称为无参函数(表明它们的元数或函数总量为0)。作为函数,它们返回的值可能永远不变,因此它们允许将常量当做函数。在
Java 8,它们的职责是根据可变语境来返回各种值。因此,它们不是函数。
真是太乱了!而且这些接口的方法有不同的名字。对象函数有个方法叫 apply
,返回数字化原语的方法被称为 applyAsInt
、applyAsLong
,或 applyAsDouble
。返回boolean
的函数有个方法被称为 test
,供应商的方法叫做 get
或getAsInt
、getAsLong
、 getAsDouble
,或 getAsBoolean
。(他们没敢把带有 test
方法、不带函数的 BooleanSupplier
称为“谓语”。笔者真的很好奇为什么!)
值得注意的一点,是并没有对应 byte
、 char
、 short
和 float
的函数,也没有对应两个以上元数的函数。
不用说,这样真是太荒谬了,然而我们又不得不坚持下去。只要 Java 能推断类型,我们就会觉得一切顺利。然而,一旦试图通过功能方式控制函数,你将会很快面对 Java 无法推断类型的难题。最糟糕的是,有时候 Java 能够推断类型,却会保持沉默,继续使用另外一个类型,而不是我们想用的那一个。
如何发现正确类型
假设笔者想使用三个参数的函数。由于 Java 8没有现成可用的功能接口,笔者只有一个选择:创建自己的功能接口,或者如前文(Java 8 怎么了之一)中所说,采取柯里化。创建三个对象参数、并返回对象的功能接口直截了当:
interface Function<T, U, V, R> {
R apply(T, t, U, u, V, v);
}
不过,可能出现两种问题。第一种,可能需要处理原语。参数类型也帮不上忙。你可以创建函数的特殊形式,使用原语,而不是对象。最后,算上8类原语、3个参数和1个返回值,只不过得到6561中该函数的不同版本。你以为甲骨文公司为什么没有在 Java 8中包含 TriFunction
?(准确来说,他们只放了有限数量的 BiFunction
,参数为Object
,返回类型为 int
、long
或double
,或者参数和返回类型同为 int、long 或 Object,产生729种可能性中的9种结果。)
更好的解决办法是使用拆箱。只需要使用 Integer
、Long
、Boolean
等等,接下来就让 Java 去处理。任何其他行动都会成为万恶之源,例如过早优化(详见http://c2.com/cgi/wiki?PrematureOptimization)。
另外一个办法(除了创建三个参数的功能接口之外)就是采取柯里化。如果参数不在同一时间求值,就会强制柯里化。而且它还允许只用一种参数的函数,将可能的函数数量限制在81之内。如果只使用 boolean
、int
、long
和double
,这个数字就会降到25(4个原语类型加上两个位置的 Object
相当于5 x 5)。
问题在于在对返回原语,或将原语作为参数的函数来说,使用柯里化可能有些困难。以下是前文(Java 8怎么了之一)中使用的同一例子,不过现在用了原语:
IntFunction<IntFunction<IntUnaryOperator>>
intToIntCalculation = x -> y -> z -> x + y * z;
private IntStream calculate(IntStream stream, int a) {
return stream.map(intToIntCalculation.apply(b).apply(a));
}
IntStream stream = IntStream.of(1, 2, 3, 4, 5);
IntStream newStream = calculate(stream, 3);
注意结果不是“包含值5、8、11、14和17的流”,一开始的流也不会包含值1、2、3、4和5。newStream
在这个阶段并没有求值,因此不包含值。(下篇文章将讨论这个问题)。
为了查看结果,就要对这个流求值,也许通过绑定一个终端操作来强制执行。可以通过调用 collect
方法。不过在这个操作之前,笔者要利用 boxed
方法将结果与一个非终端函数绑定在一起。boxed
方法将流与一个能够把原语转为对应对象的函数绑定在一起。这可以简化求值过程:
System.out.println(newStream.boxed().collect(toList()));
这显示为:
[5,8, 11, 14, 17]
也可以使用匿名函数。不过,Java 不能推断类型,所以笔者必须提供协助:
private IntStream calculate(IntStream stream, int a) {
return stream.map(((IntFunction<IntFunction<IntUnaryOperator>>) x -> y -> z -> x + y * z).apply(b).apply(a));
}
IntStream stream = IntStream.of(1, 2, 3, 4, 5);
IntStream newStream = calculate(stream, 3);
柯里化本身很简单,只要别忘了笔者在其他文章中提到过的一点:
(x, y, z) -> w
解读为:
x -> y -> z -> w
寻找正确类型稍微复杂一些。要记住,每次使用一个参数,都会返回一个函数,因此你需要一个从参数类型到对象类型的函数(因为函数就是对象)。在本例中,每个参数类型都是 int
,因此需要使用经过返回函数类型参数化的 IntFunction。由于最终类型为IntUnaryOperator
(这是 IntStream
类的 map
方法的要求),结果如下:
IntFunction<IntFunction<...<IntUnaryOperator>>>
笔者采用了三个参数中的两种,所有参数类型都是 int
,因此类型如下:
IntFunction<IntFunction<IntUnaryOperator>>
可以与使用自动装箱版本进行比较:
Function<Integer, Function<Integer, Function<Integer, Integer>>>
如果你无法决定正确类型,可以从使用自动装箱开始,只要替换上你需要的最终类型(因为它就是 map
参数的类型):
Function<Integer, Function<Integer, IntUnaryOperator>>
注意,你可能正好在你的程序中使用了这种类型:
private IntStream calculate(IntStream stream, int a) {
return stream.map(((Function<Integer, Function<Integer, IntUnaryOperator>>) x -> y -> z -> x + y * z).apply(b).apply(a));
}
IntStream stream = IntStream.of(1, 2, 3, 4, 5);
IntStream newStream = calculate(stream, 3);
接下来可以用你使用的原语版本来替换每个 Function<Integer...
,如下所示:
private IntStream calculate(IntStream stream, int a) {
return stream.map(((Function<Integer, IntFunction<IntUnaryOperator>>) x -> y -> z -> x + y * z).apply(b).apply(a)); }
然后是:
private IntStream calculate(IntStream stream, int a) { return stream.map(((IntFunction<IntFunction<IntUnaryOperator>>) x -> y -> z -> x + y * z).apply(b).apply(a)); }
注意,三个版本都可编译运行,唯一的区别在于是否使用了自动装箱。
何时匿名
在以上例子中可见,lambdas 很擅长简化匿名类的创建,但是不给创建的范例命名实在没有理由。命名函数的用处包括:
- 函数复用
- 函数测试
- 函数替换
- 程序维护
- 程序文档管理
命名函数加上柯里化能够让函数完全独立于环境(“引用透明性”),让程序更安全、更模块化。不过这也存在难度。使用原语增加了辨别柯里化函数类别的难度。更糟糕的是,原语并不是可使用的正确业务类型,因此编译器也帮不上忙。具体原因请看以下例子:
double tax = 10.24;
double limit = 500.0;
double delivery = 35.50;
DoubleStream stream3 = DoubleStream.of(234.23, 567.45, 344.12, 765.00);
DoubleStream stream4 = stream3.map(x -> {
double total = x / 100 * (100 + tax);
if ( total > limit) {
total = total + delivery;
}
return total;
});
要用命名的柯里化函数来替代匿名“捕捉”函数,确定正确类型并不难。有4个参数,返回 DoubleUnaryOperator
,那么类型应该是DoubleFunction<DoubleFunction<DoubleFunction<DoubleUnaryOperator>>>
。不过,很容易错放参数位置:
DoubleFunction<DoubleFunction<DoubleFunction<DoubleUnaryOperator>>> computeTotal = x -> y -> z -> w -> {
double total = w / 100 * (100 + x);
if (total > y) {
total = total + z;
}
return total;
};
DoubleStream stream2 = stream.map(computeTotal.apply(tax).apply(limit).apply(delivery));
你怎么确定 x
、y
、z
和 w
是什么?实际上有个简单的规则:通过直接使用方法求值的参数在第一位,按照使用方法的顺序,例如,tax
、limit
、delivery
对应的就是 x
、y
和 z
。来自流的参数最后使用,因此它对应的是 w
。
不过还存在一个问题:如果函数通过测试,我们知道它是正确的,但是没有办法确保它被正确使用。举个例子,如果我们使用参数的顺序不对:
DoubleStream stream2 = stream.map(computeTotal.apply(limit).apply(tax).apply(delivery));
就会得到:
[1440.8799999999999, 3440.2000000000003, 2100.2200000000003, 4625.5]
而不是:
[258.215152, 661.05688, 379.357888, 878.836]
这就意味着不仅需要测试函数,还要测试它的每次使用。如果能够确保使用顺序不对的参数不会被编译,岂不是很好?
这就是使用正确类型体系的所有内容。将原语用于业务类型并不好,从来就没有好结果。但是现在有了函数,就更多了一条不要这么做的理由。这个问题将在其他文章中详细讨论。
敬请期待
本文介绍了使用原语大概比使用对象更为复杂。在 Java 8中使用原语的函数一团糟,不过还有更糟糕的。在下一篇文章中,笔者将谈论在流中使用原语。
OneAPM 能为您提供端到端的 Java 应用性能解决方案,我们支持所有常见的 Java 框架及应用服务器,助您快速发现系统瓶颈,定位异常根本原因。分钟级部署,即刻体验,Java 监控从来没有如此简单。想阅读更多技术文章,请访问 OneAPM 官方技术博客。
本文转自 OneAPM 官方博客
原文地址: https://dzone.com/articles/whats-wrong-java-8-part-ii