颠覆认知:一向主张可扩展性的Java,为何要推出封闭类?

你好,我是猿java。

当你还在 JDK 8驰骋沙场,大张旗鼓搞可扩展性时,JDK 15却已暗度陈仓:”偷偷摸摸”搞起了 Sealed Classes(封闭类)的功能,为何一向主张可扩展性的 Java,却会反其道而行之,推出封闭类这个功能?今天就让我们一起来聊聊这期中的原委。

申明:本文基于 jdk-17.0.5

2020年,给 JDK 15增加 Sealed Classes(封闭类)的提案被提交,在经历了 JDK 16版本的迭代后,最终该功能在 JDK 17正式发布,Sealed Classes发展的 JEP如下:

img.png

JEP: JDK Enhancement Proposal, JDK增强建议,JEP是一个JDK核心技术相关的增强建议文档;

什么是封闭类

Sealed Classes:翻译为 密封类、封闭类。代表该类/接口是一个封闭的类/接口,只有许可的类/接口 才能继承或实现该类/接口。如下图来自 JDK真实封闭类源码:

img.png

img.png

因此,用 sealed关键字修饰的类就是封闭类。

为什么需要封闭类

像Java 这种面向对象的编程语言,可扩展性是衡量设计优劣的一个重要指标,可是 Java为何要引入封闭类? 这不是明晃晃的限制扩展性吗?

其实,这是安全性和扩展性权衡的一个结果。

可能有小伙伴会说:控制继承能力,用 Java现有的方式就ok,为何还需要多增加一个封闭类呢?

那我们先看看 Java现有的 2种控制继承能力的方法:

  • 用关键字 final修饰类,类就成了终态类,无法被继承;比如我们经常使用的 String类。

img.png

将类定义为 final后,类就完全失去了扩展性,简单粗暴,适合完全不需要扩展的类/接口。

  • package-private类,也就是非 public类,这样只有同包下的类才能继承,比如:java.nio中的 Bits类;

img.png

将类申明为非 public(package-private),只有同包下的类才能继承,尽管在同包下还是保留了扩展,但是可能会出现下面的安全问题。

再来看看继承带来的安全问题:

如下代码为 java.io.FileCleanable 源码,该类主要是用来清理文件。在 JDK中,FileCleanable类被申明成 final,也就意味着该类不能被继承,不能被扩展了,为什么要把FileCleanable类申明成 final呢?

1
2
3
4
5
6
7
8
9
10
final class FileCleanable extends PhantomCleanable<FileDescriptor> {

// 省略部分代码
@Override
public void clear() {
if (remove()) {
super.clear();
}
}
}

假如去掉 FileCleanable类的final关键字,因此就可以实现自定义类 MyFileCleanable去继承 MyFileCleanable类,并且覆写 clear(),或者新增add()方法,代码示例如下,这样会带来什么问题呢?

1
2
3
4
5
6
7
8
9
10
11
12
13
public class MyFileCleanable extends FileCleanable {

// 省略代码
@Override
public void clear() {
// 实现自定义文件删除逻辑,删除所有文件
cearAllFolders();
}

public void add(){

}
}

原本 FileCleanable类中的 clear方法只能JVM 内部调用,如果开放扩展性,自定义类就可以覆写clear()方法,因此可以任意修改 clear()的逻辑,假如用户A 本来并没有操作clear()的权限,但是因为类的继承扩展而获得了该权限,如果不小心删除了重要文件,结果可能是直接去财务室结账走人…

因此子类继承父类,获得扩展性主要会带来2个影响:

  • 子类可以覆写父类中的现有方法;
  • 子类可以为父类添加新方法;

上述两个影响都可能带来安全性的问题,因此我们在设类时需要多思考一些安全性相关的问题:

  • 类有没有必要被子类扩展,被扩展后会不会有安全问题,该类能不能被定义成 final?
  • 类中的方法,被子类拿到会不会有安全问题,能不能被定义成 final?

综上,使用 final和 package-private 两种限制方式的粒度都比较粗,不限制的话又可能带来一些安全隐患,所以我们就会想,有没有粒度细一点又能解决安全隐患的问题,因此,封闭类就”粉墨登场”了。

如何使用封闭类

有了封闭类,要如何使用呢?我们先看下 JDK 12引入的几个源码类(在jdk 17 中被加上了 sealed修饰):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
public sealed interface ConstantDesc
permits ClassDesc,
MethodHandleDesc,
MethodTypeDesc,
Double,
DynamicConstantDesc,
Float,
Integer,
Long,
String {

// 省略代码
}

public sealed interface ClassDesc
extends ConstantDesc,
TypeDescriptor.OfField<ClassDesc>
permits PrimitiveClassDescImpl,
ReferenceClassDescImpl {

// 省略代码
}

final class PrimitiveClassDescImpl
extends DynamicConstantDesc<Class<?>> implements ClassDesc {

// 省略代码
}

public abstract non-sealed class DynamicConstantDesc<T>
implements ConstantDesc {

// 省略代码
}

在解释上述源码之前,铺垫 JDK 17中因密封类而增加了几个重要关键词:

  1. sealed:(封闭)用于修饰类/接口,代表这个类/接口为密封类/接口;
  2. non-sealed:(非封闭)用于修饰类/接口,代表这个类/接口为非密封类/接口;
  3. permits:(允许)用于 extends和 implements之后,指定能够继承或实现封闭类的子类/接口;

了解了 JDK17增加的几个关键字之后,我们再来分析上面的源码,从源码中我们可以发现,sealed 通常和 permits关键字一起使用。

首先通过关键字 sealed申明一个封闭的接口 ConstantDesc,然后用 permits关键字允许 ClassDesc,
MethodHandleDesc,
MethodTypeDesc,
Double,
DynamicConstantDesc,
Float,
Integer,
Long,
String 能够实现或者继承 ConstantDesc这个接口。

然后,扩展类 PrimitiveClassDescImpl 定义成 final,代表它是一个终态类,无法被继承,DynamicConstantDesc 被定义成 non-sealed,代表它的子类还可以继续继承扩展它。

最后,我们对封闭类总结如下:

  1. 申明封闭类:在类前面加 sealed关键字;
  2. 给封闭类开放扩展权限:在类声明后加上 permits关键字,后面加上需要授权的类;
  3. 许可类可以申明成 final,关闭扩展性;可以声明为 sealed,延续扩展性;也可以申明成 non-sealed,支持扩展性不受限;
  4. permits 关键字指定的许可子类(permitted subclasses),必须和封闭类处于同一模块(module)或者包空间(package)里;

总结

  • sealed通常和 permits关键字一起使用;
  • sealed封闭类提供了更精细粒度的可扩展性;
  • sealed封闭类可以更好地控制代码的安全性和健壮性;
  • 尽管目前国内大部分业务的代码还是运行在 JDK8环境上,但是了解 JDK的新特性对可以帮助我们更好的了解它以后的一个发展趋势;

学习交流

文章总结不易,如果你觉得文章有帮助,请帮忙转发给更多的好友,或关注公众号:猿java,持续输出硬核文章。

drawing