wxMEdit 是对编码和十六进制编辑支持很好的文本编辑器，尤其是在十六进制模式下也能支持各种编码。 wxMEdit 是 MadEdit 的后继，并对其做了很多改进。下载地址为：

https://wxmedit.github.io/zh_CN/downloads.html

欢迎大家下载使用，有问题可以在 GitHub 上反馈或者通过其他方式联系我。

wxMEdit 3.2 由共同维护人 jerome KASPER 重新设计了图标，包括程序主图标及菜单/工具栏图标，给人耳目一新之感。 jerome KASPER 同时还为 wxMEdit 添加了法文翻译。

wxMEdit 3.2 的重大改进还有： 新增 Win64、国产发行版以及 RISC-V 架构的包， 支持国家最新中文编码标准 GB18030-2022， Unicode 支持到 15.0， Windows 下支持 High DPI， 支持 GTK + 3 与 Wayland， 调整了一部分快捷键。

调整快捷键是个不兼容变更，主要是去掉冲突、冗余的快捷键，增加小键盘快捷键，参见 wxMEdit 3.2 中的快捷键变更。

wxMEdit 3.2 相比 wxMEdit 3.1 兼容性更好、更加稳定，修复了多个崩溃问题、兼容性问题以及一些其他小问题。 其中有一个值得一提的是修复 AltGr 输入字符问题， 国内可能用这个功能比较少（也有，比如切换到支持输入拼音声调键盘布局），欧美用到的更多一些。 从 2018 年到今年也花了很多精力定位及修复该问题。 期间了解到 Windows 下的 AltGr 与 Ctrl-Alt 等效，wxWidgets 也采取了相同方案， 这也是调整部分快捷键的一个原因，将原有的 7 个 Ctrl-Alt-字母 快捷键调整为 Shift-Alt-字母。

此外 wxMEdit 3.2 所打发布包也与以往不同。 对于 Windows 版，新增了原生 Windows 64 位的包，同时提供了 7-zip 与 zip 格式； 另外为了解决新版 ICU 库不支持 Windows XP 的问题，用到了 VC-LTL 与 YY-Thunks， 经验证完全解决了 XP 的问题； 不过有点遗憾的是这样打出来的包在 ReactOS 下无法运行，因此为 ReactOS 单独打包，ReactOS 包的 ICU 版本停留在 58，只能支持到 Unicode 9。 而为 Linux 发行版打包才是大头，这个周末打了好多包。除了为国际主流发行版打包外，还支持了国产根社区的三个发行版：openEuler、openKylin、deepin （另外两个 OpenAnolis、OpenCloudOS 的根社区版未提供 wxWidgets，无法打包）。 此外，由于 RISC-V 生态的兴起，wxMEdit 3.2 也为多款操作系统（Ubuntu、FreeBSD、openSUSE、openEuler、openKylin、deepin）提供 RISC-V 架构的包，但是由于打包环境问题，还有几个未完成，将会在接下来一两周内补上。

wxMEdit 3.2 的改动记录如下：

1. 添加新功能：以人类可读的格式显示文件大小。
2. 添加了始终使用特定编码打开文件的选项。
3. 新增对 GTK+ 3 以及 Wayland 的支持。
4. 新增对 Windows 下的 High DPI 的支持。
5. 重新设计了图标（由 jerome KASPER 设计）。
6. 更改了一些快捷键，请参见 wxMEdit 3.2 中的快捷键变更。
7. 将 GB18030 支持更新到了最新标准 GB18030-2022。
8. 更新了 Unicode 15.0 的 Unicode 块描述（需要 ICU 72 或更高版本）
9. 修复了文本模式下行长超过限制时导致崩溃的问题。
10. 修复了在“关于 wxMEdit”对话框点击“确定”按钮时导致崩溃的问题。
11. 修复了在按窗口自动换行时文本中包含一些制表符导致无法响应的问题。
12. 修复了 wxMEdit 3.1 中破坏的三击选中一行的行为。
13. 修复了（使用 wxMSW-2.8 构建的）MadEdit/wxMEdit 中信息窗口每次高度减少 4 的问题。
14. 修复了重启后字体与编码未恢复的问题。
15. 修复了无法通过 AltGr 输入字符的问题。
16. 修复了 Linux 下光标闪烁与选区反色的渲染问题。
17. 修复了 Windows 10 下 IME 候选窗口不跟随光标的问题。
18. 添加了法文翻译（jerome KASPER）。
19. 更新了简体中文翻译。
20. 其他小修改及问题修复。

修订记录

2023-07-10：小调整并附图

这个系列以练习为主，可能不会有多少讲述（当然本篇例外），可以作为初学者的自学验收之用。

Java 中有非受限的空值，并且不知哪时会引发 NPE（即 NullPointerException），解决这个问题对于 Android 开发来说很简单——用 Kotlin 就好了。 其实不仅限于 Android，对于服务端开发来说终极方案也应该是迁移到 Kotlin。 因为只要用 Java，空值问题就没办法彻底解决（之前在《现代编程语言系列2：安全表达可选值》中也提到过这点），而 JVM 平台主流工业级语言中只有 Kotlin 很好地解决了这一问题。

但是对于服务端开发来说，常有各种非技术原因不能在项目中以 Kotlin 取代 Java，对于这些项目来说显然没办法彻底解决空值问题。 那么有没有一些方法与工具可以让空值问题处理起来尽可能规范、简易些呢？这里有几点经验分享。

NPE 防御

一些典型场景的 NPE 可以通过编码习惯来防御——某些静态分析工具或许也能检测到一些问题，但很难完美覆盖； 没办法，只能通过编码规范、程序员的自律来解决了。 其中比较常见的两个场景是空值比较以及使用不可变集合。

空值比较

对实际值为 null 的变量调用包括 equals() 在内的任何方法都会导致 NPE。 因此比较可空值（通常为变量）与非空值（通常为常量，不尽然）时，以可空值为参数对非空值调 equals() 即可避免这个问题。 例如：

if ("Hello".equals(nullableStr)) {
    ……
}

如果比较两个可空值怎么办呢？用 Objects.equals()，例如：

if (Objects.equals(nullableObj1, nullableObj2)) {
    ……
}

不可变集合不支持空值

Java 9 引入的 List.of()、Set.of()、Map.of()、Map.entry() 以及 Java 10 引入的 List.copyOf()、Set.copyOf()、Map.copyOf()、Collectors.toUnmodifiableList()、Collectors.toUnmodifiableSet()、Collectors.toUnmodifiableMap() 等均不支持 null，其中构造不可变的 Map 与 Map.Entry 时 key、value 均不能为 null。 还需要注意的一点是不能以 null 值调用不可变集合的 contains() / containsKey() / containsValue() / containsAll() 方法，其中 containsAll() 还要求参数集合中不能有 null。

例如：

List.of("a", null); // NPE：元素不可以有空值
Map.of("a", 1, null, 2); // NPE：key 不可有空值
Map.of("a", 1, "b", null); // NPE：value 不可有空值
Map.entry("hello", null); // NPE：value 不可有空值

var map = new HashMap<String, Integer>();
map.put("a", 1);
Map.copyOf(map); // OK
map.put(null, 2);
Map.copyOf(map); // NPE：key 不可有空值

// NPE：元素不可以有空值
Stream.of((String)null).collect(Collectors.toUnmodifiableList()); 

// NPE：不能用 null 调用不可变集合的 containsKey() 方法
Map.of("a", "b").containsKey(null);

千万不要因为这点而放弃不可变集合。 不可变集合本身有很多优势，Java 10 及以后版本也推荐使用不可变集合。 只是需要特别注意上述几点：构造字面值时不能有 null、调用 contains() / containsKey() 等之前需要判断参数是否为 null、调用 collect() / copyOf() / containsAll() 之前去除参数集合中的 null 值。 例如：

var isInSet = nullableStr != null && Set.of("hello", "world").contains(nullableStr);

Stream.of("hello", (String)null, "world").filter(Objects::nonNull).collect(Collectors.toList());

var map = new HashMap<String, Integer>();
map.put("a", 1);
map.put(null, 2);
map.put("b", null);

map.entrySet().stream()
        .filter(entry -> entry.getKey() != null && entry.getValue() != null)
        .collect(Collectors.toUnmodifiableMap(Map.Entry::getKey, Map.Entry::getValue));

Optional

Java 中解决可选值问题，首先应该想到的就是 Optional。 Optional 是 Java 8 引入的可选值类型，用于在很多场景中取代 null 来表达可选值，进而避免 null 所带来问题。

Optional 的用法

Optional 的核心方法有 map()、flatMap()、orElse() 与 orElseGet()。

map()：由一个可选值得到另一个可选值

例如对于一个可选的字符串，计算其长度：

var lengthOpt = Optional.ofNullable(nullableString).map(String::length);

flatMap()：处理可选值嵌套情况

例如，从可空整数列表中取第一个正值，从列表中取第一个元素可以用 Stream<Integer>#findFirst()，该方法返回 Optional<Integer>，如果继续用 map() 的话，会得到可选值的可选值：

Optional<Optional<Integer>> intOptOpt = Optional.ofNullable(nullableIntList).map(intList ->
        intList.stream().filter(i -> i > 0).findFirst()
);

而用 flatMap() 会将两层 Optional 打平为一层：

Optional<Integer> intOpt = Optional.ofNullable(nullableIntList).flatMap(intList ->
        intList.stream().filter(i -> i > 0).findFirst()
);

orElse()、orElseGet()：由可选值得到值，如果无值取默认值

例如，对于可选字符串，有值取长度，无值取 0，可以用 orElse() 得到一个整数：

int length = strOpt.map(String::length).orElse(0);

如果默认值需要惰性求值，那么还可以用 orElseGet()：

int lengthOrRandom = strOpt.map(String::length).orElseGet(() ->
        new Random().nextInt()
);

还有一个特别的场景，就是将 Optional<T> 转换为可空的 T 值时千万不能想当然地调 get()——它在无值时抛 NoSuchElementException 而不是返回 null（参见其文档）。 正确的方式是 orElse(null)。例如：

Integer lengthOrNull = strOpt.map(String::length).orElse(null);

Optional 的其他方法在特定场景也很实用，由于方法不多，大家可以直接读其文档，在此不再赘述。

Optional 的问题

很多文章称 Optional 是 Java 8 针对 NPE 问题甚至十亿美元问题的解决方案，实际上远非如此。且不说在 Java 中没办法强制使用 Optional 而不用 null，即便 Optional 自身用起来也有很多局限性。

Optional 对象自身也可能为 null

一个特别坑的问题是 Optional 是引用类型，因此一个 Optional 对象自身也可能为 null，例如：

Optional<String> strOpt = null;
strOpt.map(String::length); // NPE

当然 Optional 的官方文档称 Optional 类型值不应该为 null，在 IDEA 中写上述代码也会标出警告，但 Java 语法与编译器并不会为此提供任何保障或约束。

Optional 不可序列化

Optional 不可序列化，这就意味着需要序列化的场景还得用 null 来表达可选值，这也是上文特别提到由 Optional 转换可空值的主要原因。 鉴于此，Optional 不适合作为类的字段，也不适合作为方法的入参，只适用于局部变量、返回值以及表达式中间结果等场景。 IDEA 也会对 Optional 用作字段或者参数时标记警告。

不够简洁

与受限空值语法相比，Optional 用法要冗长的多，当然这很符合 Java 的历史风格。 对于受限空值的 ?. 语法，Optional 要用 map() 与 flatMap()；对于 ?:/?? 语法要用 orElse() 或 orElseGet()。 其实对于采用可选值类型的其他语言来说可能都有类似问题，但是 Haskell、Scala 有推导式，Haskell、Scala、OCaml、F# 等语言还支持自定义操作符，从而简化可选值的用法。 不幸的是 Java 不具备这些语法。

可空性注解

在 Java 中没办法强制区分可空与非空类型，而有时又希望能在字段、参数或者返回值上标注是否可空，以便 IDE 或者其他静态检查工具能够识别并给出提醒。

我们看个示例，实现一个简陋版的 ?:/??：

public static <T> T defaultWith(T obj, T defaultVal) {
    return Optional.of(obj).orElse(defaultVal);
}

当 obj 非空时该方法返回 obj，否则返回 defaultVal。 但是实际上事与愿违，这个方法在 obj 为空时不会返回 defaultVal，而是抛 NPE。 原因是 Optional.of() 只接受非空参数，如果参数为空就会抛 NPE。 遗憾的是编写与编译这段代码都不会收到任何警告或提醒，因为无论 IDE 还是编译器都无从知晓这个方法的入参 obj 可能为空。

此时，如果我们给 obj 加一个 org.jetbrains.annotations.Nullable 注解，IDEA 就会对方法中使用 obj 调用 Optional.of() 标出警告提醒：“Argument ‘obj’ might be null”。 改为调用 Optional.ofNullable() 警告就消失了。 而如果希望 defaultVal 要求非空的话，还可以对 defaultVal 标注 org.jetbrains.annotations.NotNull，这样一来方法的返回值也会非空，同样可以标注 NotNull：

@NotNull
public static <T> T defaultWith(@Nullable T obj, @NotNull T defaultVal) {
    return Optional.ofNullable(obj).orElse(defaultVal);
}

当然，这只是关于可空性注解使用场景的一个示例，实际上并不需要我们自己造一个这样的轮子，因为有现成的轮子可用（见下文）。 上述 Nullable 与 NotNull 两个注解来自于 JetBrains 的 java-annotations。类似的还有 Checker Framework 的 Nullness Checker、spotbugs-annotations、Lombok 的 NonNull 等。

Apache Commons

Apache Commons 有多个库提供了简化空值使用的工具。例如实现类似 ?:/?? 的功能，使用 Optional 需要这样写：

var nonNullVal = Optional.ofNullable(obj).orElse(nonNullDefault);

而使用 Apache Commons 只需调用一个类似上文实现的静态方法就可以了。

StringUtils

StringUtils 是 Commons Lang 中的一个工具类，其中包含一系列与字符串空值相关的方法。

isEmpty() 与 isNotEmpty()

前者判断一个字符序列是否为 null 或空序列，后者与之相反——判断一个字符序列既非 null 也非空序列。 这两个方法非常实用，现实业务中对字符串为 null 或空串时走同样处理分支的场景很常见。

defaultString()

defaultString(str, defaultStr) 如果 str 非 null 返回 str，否则返回 defaultStr。 还有一个单参重载版本：defaultString(str) 如果非 null 返回 str，否则返回空串。

defaultIfEmpty()

defaultIfEmpty(str, defaultStr) 如果 str 既非 null 也非空串返回 str，否则返回 defaultStr。

getIfEmpty()

相当于默认值采用惰性求值的 defaultIfEmpty()，getIfEmpty(str, () -> ……) 当 str 既非 null 也非空串时返回 str，否则对 lambda 表达式求值并以其返回值作为 getIfEmpty() 的返回值。

firstNonEmpty()

对于一系列值，返回第一个既非 null 也非空串的。

isAllEmpty()、isAnyEmpty()、isNoneEmpty()

对于一系列值，判断是否全都是、其中有、全都不是 null 或空串。

除了这些明显与空值相关的方法外，StringUtils 的其他方法也都会对 null 特殊处理而不是引发 NPE（个别的会抛其他异常）。

Commons Collections

与 StringUtils 类似，Commons Collections 中的 CollectionUtils、IterableUtils、ListUtils、SetUtils、MapUtils 等也有提供 null 与空集合合并处理的方法，只是没有那么丰富。

emptyIfNull()

CollectionUtils、IterableUtils、ListUtils、SetUtils、MapUtils 等均有提供该方法，如果参数非 null 返回参数本身，否则返回对应类型的空集合。

isEmpty() 与 isNotEmpty()

CollectionUtils（可以用于 Collection 及其子类型如 List、Set） 与 MapUtils 提供了这两个方法。前者判断是否为 null 或为空集合，后者相反——判断既非 null 也非空集合。

CollectionUtils、IterableUtils、ListUtils、SetUtils、MapUtils 等提供的大多数其他方法也都会对 null 特殊处理而不是引发 NPE，个别会抛 NPE 的方法文档中也有说明。

ObjectUtils

更通用的情况还可以用 Commons Lang 中的工具类 ObjectUtils。

defaultIfNull()

类似上文自行实现的 defaultWith()，不过并没有标可空性注解。 defaultIfNull(obj, defaultVal) 当 obj 非空时返回 obj 否则返回 defaultVal。

getIfNull()

相当于默认值采用惰性求值的 defaultIfNull()，getIfNull(obj, () -> ……) 当 obj 非空时返回 obj，否则对 lambda 表达式求值并以其返回值作为 getIfNull() 的返回值。

firstNonNull()

对于一系列值，返回第一个非空的。

getFirstNonNull()

可以看作是惰性求值版的 firstNonNull()，对于一系列求值过程返回第一个求值结果非空的结果。 例如 getFirstNonNull(() -> null, () -> "hello", () -> throw new IllegalStateException()) 会返回 "hello" 而不会执行后面的求值过程，因此不会抛 IllegalStateException。

allNotNull、allNull、anyNotNull、anyNull

对于一系列值，判断是否全都非、全都是、其中有非、其中有空值。

ObjectUtils 中的大多数其他方法也都会对空值特殊处理而不是引发 NPE。除了 StringUtils、ObjectUtils 之外，Commons Lang 中的 BooleanUtils、NumberUtils 也都提供了一系列空安全的工具方法。

其他

抛砖引玉，欢迎补充。

小结

Java 语言自身目前没办法彻底解决空值问题，不过有一些方法、工具可以用：

• NPE 防御：空值比较、不可变集合不支持空值
• Optional
• 可空性注解
• Apache Commons

光说不练无异于纸上谈兵，接下来的练习才是重中之重。

练习

以下练习中未标注解的变量，如果变量名以 x 开头也表示可能为空。

为什么不直接用 nullableXyz 这种更明显的方式？因为现实代码中通常更不明显。

1、 纠错

if (xMethod.equals("POST")) {
   doPost();
}

if (xArg1.equals(xArg2)) {
    System.out.println("arg1 == arg2");
}

2、纠错

var map1 = Map.of("abc", 10, "def", 20, xStr, 30);

var list1 = Arrays.asList(1, 2, -3, 9, null, 15);
var set1 = Set.copyOf(list1);

if (Map.of("hello", 1, "world", 2).containsKey(xStr)) {
    System.out.println("either 'hello' or 'world'");
}

3、加注可空性注解

public static <T, U> U mapSome(T x, Function<T, U> mapper) {
    return x == null ? null: mapper.apply(x);
}

4、用 Optional 重构上题 mapSome()

注：只是练习 Optional 的使用，上题的实现并不需要以 Optional 取代。

5、用 Optional 重构

Integer xInt = Math.random() > 0.8 ? null : Math.random() > 0.5 ? 5 : 12;

// 重构以下代码
var x1 = (xInt == null || xInt % 2 != 0) ? null : xInt / 2;
if (x1 != null) {
    System.out.println(x1);
}

6、用 Optional 重构 getTitledContent()

@NotNull
public static String getUpperTitle(@Nullable Post post) {
    if (post == null || post.getTitle() == null) {
        log.warning("no title")
        return "- UNTITLED -";
    }

    return post.getTitle().toUpperCase();
}

public class Post {
    @Nullable
    public String getTitle();
}

7、用 StringUtils 将 getChoice() 的实现重构成一行代码

String getChoice(String choice, boolean highest) {
    if (choice != null && !choice.isEmpty())
        return choice;

    if (highest)
        return "High";

    return "Low";
}

8、使用 Common Collections 重构 getIdsString()

private static final List<Integer> IMPLICIT_IDS = List.of(101, 111, 191);
public static String getIdsString(@Nullable Collection<@NotNull Integer> ids) {
    if (ids == null) {
        return IMPLICIT_IDS.stream()
                .map(Object::toString)
                .collect(Collectors.joining());
    }

    return Stream.concat(ids.stream(), IMPLICIT_IDS.stream())
            .map(Object::toString)
            .collect(Collectors.joining());
}

9、使用 BooleanUtils 重构

public static String toHex(int n, @Nullable Boolean useUpper) {
    String s = Integer.toString(n, 16);
    return useUpper != null && useUpper ? s.toUpperCase() : s;
}

10、使用 ObjectUtils 重构

public static Instant tomorrowOf(@Nullable Instant x) {
    if (x == null) {
        log.debug("the base Date is null");
        x = Instant.now();
    }
    
    return x.plus(Duration.ofDays(1));
}

虽然不能说 Java 就是借鉴的它们（毕竟这些特性既非它们独有也非它们首创），但可以说是 Java 官方对 Kotlin/Scala 这些特性的充分肯定。而这些新特性也让 Java 向现代语言的方向又迈进了一些，我们逐个来看。

switch 表达式

Java 12 预览、Java 13 二次预览、Java 14 正式。

相当于只支持值匹配的 Kotlin when 表达式/Scala match 表达式。

我们看一个不严谨的示例：判断一个非空对象对应哪种 JSON 类型，使用传统的 switch 语句实现如下：

switch (obj.getClass().getSimpleName()) {
    case "Integer":
    case "Long":
    case "Float":
    case "Double":
        System.out.println("number");
        break;
    case "List":
    case "Set":
        System.out.println("array");
        break;
    case "String":
        System.out.println("string");
        break;
    case "Boolean":
        System.out.println("boolean");
        break;
    case "Map":
        System.out.println("object");
        break;
    default:
        System.out.println("object/unknown");
}

而使用 switch 表达式可以简化为：

switch (obj.getClass().getSimpleName()) {
    case "Integer", "Long", "Float", "Double" -> System.out.println("number");
    case "List", "Set" -> System.out.println("array");
    case "String" -> System.out.println("string");
    case "Boolean" -> System.out.println("boolean");
    case "Map" -> System.out.println("object");
    default -> System.out.println("object/unknown");
}

是不是简洁了很多？当然如果只能这样用，那还称不上 switch 表达式，既然是表达式那么一定可以有一个返回值。 我们可以利用 switch 表达式的返回值来进一步重构上述代码：

String jsonType = switch (obj.getClass().getSimpleName()) {
    case "Integer", "Long", "Float", "Double" -> "number";
    case "List", "Set" -> "array";
    case "String" -> "string";
    case "Boolean" -> "boolean";
    case "Map" -> "object";
    default -> "object/unknown";
};
System.out.println(jsonType);

switch 表达式中箭头的右侧不仅可以是常规表达式，还可以是一个代码块，在块中通过 yield 来指定返回值。 例如在上述 default 分支打一条错误信息，可以这样改：

String javaType = obj.getClass().getSimpleName();
String jsonType = switch (javaType) {
    case "Integer", "Long", "Float", "Double" -> "number";
    case "List", "Set" -> "array";
    case "String" -> "string";
    case "Boolean" -> "boolean";
    case "Map" -> "object";
    default -> {
        System.err.println("unknown type: " + javaType);
        yield "object";
    }
};

是不是有点类似 Kotlin 的 when 与 Scala 的 match 了？非常像，只是目前只支持简单的值匹配，还不支持 Kotlin when 的 is/in 以及 Scala match 的模式匹配。 当然如果综合 Java 12-15 引入的所有语言特性来看，不难预见 switch 表达式未来会支持模式匹配的。

switch 表达式的优点不仅是简洁且具有返回值，还避免了传统 switch 语句的一些坑（如忘记写 break 语句，再如各 case/default 子句共享同一个局部作用域）。 因此，在 Java 14 及以上版本中，应该尽量采用新语法、避免使用传统的 switch 语句。IDEA 甚至会对传统 switch 语句标记警告，并且提供了自动将传统语法重构为新语法的 quick fix 功能。

文本块

Java 13 预览、Java 14 二次预览、Java 15 正式。

Java 的文本块（多行字符串）语法与 Kotlin 原始字符串/Scala 多行字符串类似，都是采用三重双引号括起，不过具体语法、语义不尽相同。 Java 文本块起始的三重双引号后只能跟空白符和换行，因此不能像 Kotlin/Scala 那样写 """hello"""，而必须这样写：

"""
hello"""

Java 会自动去掉第一个换行以及每行末尾的空白，因此上述字符串等同于 "hello"，但是结尾处三重引号前的换行并不会去掉，例如：

// 等同于 "hello"
var s1 = """
        hello""";

// 等同于 "hello"
var s2 = """
        hello  """;

// 等同于 "hello\n"
var s3 = """
        hello
        """;

文本块中的少于连续三个的双引号都无需转义，这也是文本块的用途之一，例如：

System.out.println("""                 
        This is a string literal in Java: "Hello".""");

这段代码会输出 This is a string literal in Java: "Hello".。 编译过程中会自动去掉缩进用的空白符，如果存在多行，会以前导空白最少的一行作为基准。

文本块的另一个用途是便于书写预排版的文本，例如 ASCII Art 或者竖排文字：

String ci = "┆蝶┆觀┆月┆池┆遊┆　┆獨┆錢┆古┆來┆端┆\n" +
        "┆自┆音┆老┆畔┆人┆　┆賞┆江┆塔┆客┆陽┆\n" +
        "┆舞┆堂┆祠┆問┆醉┆　┆亦┆西┆聽┆尚┆至┆\n" +
        "┆翩┆外┆前┆奇┆　┆　┆悠┆子┆濤┆流┆　┆\n" +
        "┆躚┆雨┆人┆緣┆　┆　┆然┆匯┆於┆連┆　┆\n" +
        "┆　┆連┆絡┆　┆　┆　┆　┆吳┆越┆　┆　┆\n" +
        "┆　┆綿┆繹┆　┆　┆　┆　┆山┆地┆　┆　┆\n";

这段竖排文本是我几年前写的《雙調憶江南·庚寅年端午遊杭州》，可以看到自动格式化后第一行没有与后续几行对齐，虽然还有变通办法，但是这本身就已经比较复杂了。 而如果采用文本块就会简单很多：

String ci = """
        ┆蝶┆觀┆月┆池┆遊┆　┆獨┆錢┆古┆來┆端┆
        ┆自┆音┆老┆畔┆人┆　┆賞┆江┆塔┆客┆陽┆
        ┆舞┆堂┆祠┆問┆醉┆　┆亦┆西┆聽┆尚┆至┆
        ┆翩┆外┆前┆奇┆　┆　┆悠┆子┆濤┆流┆　┆
        ┆躚┆雨┆人┆緣┆　┆　┆然┆匯┆於┆連┆　┆
        ┆　┆連┆絡┆　┆　┆　┆　┆吳┆越┆　┆　┆
        ┆　┆綿┆繹┆　┆　┆　┆　┆山┆地┆　┆　┆
        """;

而既有双引号又有预排版的多行文本就更适合使用文本块了，例如 XML 、JSON 或其他配置/代码文本的字面值：

var languages = "[\n" +
        "  {\n" +
        "    \"name\": \"kotlin\",\n" +
        "    \"type\": \"static\"\n" +
        "  },\n" +
        "  {\n" +
        "    \"name\": \"julia\",\n" +
        "    \"type\": \"dynamic\"\n" +
        "  }\n" +
        "]";

上述 JSON 字面值看起来很凌乱，而用文本块就会清晰很多：

var languages = """
        [
          {
            "name": "kotlin",
            "type": "static"
          },
          {
            "name": "julia",
            "type": "dynamic"
          }
        ]""";

instanceof 模式匹配

Java 14 预览、Java 15 二次预览，预计 Java 16 正式。

类似于 Kotlin 的智能转换，但语法不同，在 Scala 中没有直接对应。

传统的 instanceof 判断成功之后仍然需要强制转换才能按相应类型使用，例如：

if (obj instanceof String) {
    System.out.println(((String) obj).length());
}

而使用模式匹配之后，可以在判断成功时绑定为一个对应类型的变量，之后直接使用该变量即可：

if (obj instanceof String s) {
    System.out.println(s.length());
}

需要注意的是，只有成功匹配的分支才能绑定该变量：

if (obj instanceof String s) {
    System.out.println(s.length());
} else {
    // 错误：此处 s 不可用
    // System.out.println(s.length());
}

instanceof 模式匹配不仅能用于 if 语句中，还可以用于 while 语句、三目运算符以及 &&、|| 等能使用布尔逻辑的地方，例如：

int i = obj instanceof String s ? s.length() : -1;
var isEmptyString = obj instanceof String s && s.isEmpty();
var isNotEmptyString = !(obj instanceof String s) || !s.isEmpty();

目前 Java 中只引入了这一种非常简单的模式匹配形式，未来应该会引入更多模式匹配语法。

记录类型

Java 14 预览、Java 15 二次预览，预计 Java 16 正式。

记录类型（record）类似于 Kotlin 的数据类（data class）与 Scala 的样例类（case class），只是更加严格。

在没有记录类型之前，创建一个具有各字段对应 getter、为所有字段初始化的构造函数、基于所有字段的 equals()/hashCode()/toString() 的简单类却需要写一大堆代码，其中大部分都是样板代码。 例如：

class Font {
    private final String name;
    private final int size;

    public Font(String name, int size) {
        this.name = name;
        this.size = size;
    }

    public String name() {
        return name;
    }

    public int size() {
        return size;
    }

    public boolean equals(Object o) {
        if (!(o instanceof Font other)) return false;
        return other.name.equals(name) && other.size == size;
    }

    public int hashCode() {
        return Objects.hash(name, size);
    }

    public String toString() {
        return String.format("Font[name=%s, size=%d]", name, size);
    }
}

上述代码中，除了类名、字段类型与字段名之外，其他的全部都是样板代码。而使用记录只需非常简单的一行代码即可：

record Font(String name, int size) { }

跟一般类相比，记录有以下限制：

• 总是隐式继承自 java.lang.Record 而无法显式继承任何任何类
• 记录隐含了 final 并且不能声明为抽象
• 不能显式声明字段，也不能定义初始化块
• 隐式声明的所有字段均为 final
• 如果显式声明任何会隐式生成的成员，其类型必须严格匹配
• 不能声明 native method（通常译为“本地方法”，按说应该叫“原生方法”）

除了这些限制之外，它与普通类一致：

• 用 new 实例化
• 可以在顶层声明，也可以在类内部、局部作用域中声明
• 可以声明静态方法与实例方法
• 可以声明静态字段与静态初始化块
• 可以实现接口
• 可以有其内部类型
• 可以标注注解

记录类型还可以与接下来提到的密封类/密封接口很好协作，另外记录还适用于未来版本的模式匹配。

密封类与密封接口

Java 15 预览，预计 Java 16 二次预览、Java 17 正式。

Java 15 引入的密封类（sealed class）类似于 Kotlin/Scala 的密封类、密封接口类似于 Scala 的密封特质（sealed trait）。 不妨将二者统称为密封类型，与普通类/接口不同的是，密封类型限定了哪些类/接口作为其直接子类型。例如：

sealed interface JvmLanguage
    permits DynamicTypedJvmLanguage, StaticTypedJvmLanguage {}

sealed interface StaticTypedJvmLanguage extends JvmLanguage {}
sealed class DynamicTypedJvmLanguage implements JvmLanguage
    permits Clojure, JvmScriptLanguage {}

final class Java implements StaticTypedJvmLanguage {}
final class Scala implements StaticTypedJvmLanguage {}
final class Kotlin implements StaticTypedJvmLanguage {}

final class Clojure extends DynamicTypedJvmLanguage {}
non-sealed abstract class JvmScriptLanguage extends DynamicTypedJvmLanguage {}

class Groovy extends JvmScriptLanguage {}

在密封类型的声明中可以通过 permits 显式声明其直接子类型列表，也可以省略——编译器会根据当前文件中的直接子类型的声明推断出来。 一个密封类型的直接子类型必须标注 sealed、non-sealed、final 三者之一。

密封类型与记录是相互独立的功能，但是二者能够很好协作，例如：

sealed interface Json {}
record NullVal() implements Json {}
record BooleanVal(boolean val) implements Json {}
record NumberVal(double val) implements Json {}
record StringVal(String val) implements Json {}
record ArrayVal(Object...vals) implements Json {}
record ObjectVal(Map<String, Object> kvs) implements Json {}

此外，还可以用记录与密封类型来实现代数数据类型（ADT）：记录为积类型、密封类型为和类型。 与记录类似，密封类型也将适用于未来版本的模式匹配。

小结

Java 12-15 引入了 switch 表达式、文本块、instanceof 模式匹配、记录、密封类型这几个语言新特性，这些特性在 Kotlin/Scala 中基本上都有对应，如同 Java 在追随 Kotlin/Scala 的步伐。

另外，不知大家有没有注意到这一点：除了文本块外，其他几个特性都直接或间接指向了同一个关键词——模式匹配。 这些特性除了自身价值之外，也都在为未来版本的模式匹配做铺垫。因此不妨做个大胆预测：在未来的几个版本中，Java 会引入更完善的模式匹配机制。

些许遗憾

Java 12-15 中引入语言层面的新特性并不很多，很多令人期待新特性都没有包含在内。 当然语言需要渐进式演化，这也是情理之中的事。唯有两点我觉得有些遗憾：

空安全

安全表达可选值是现代语言的一个特征，隔壁 C# 8 引入空安全的经验告诉我们： 即便语言当初做了错误的设计，倘若迷途知返，仍然能够回到正轨。 Java会不会也有这么一天？也许会，不过 Java 12-15 显然没有，在接下来的几个版本中这么做可能性也很渺茫，也许还会在“迷途”中继续前行很久。

当然关于空安全这块也不是什么长进都没有，Java 14 就有一处：JEP 358: Helpful NullPointerExceptions 改善了 NullPointerException 所携带的信息，以便定位是哪个变量出现空值导致的。

协程

协程即将成为现代工业级语言的标配，不仅 Python、JavaScript、Rust 等语言纷纷引入了协程支持（async-await 尤为便利），就连隔壁 C++ 也都已将协程纳入了今年的新标准（C++ 20）中。 再对比灵活、强大的 Kotlin 协程在异步程序设计中所带来的便利，还在坚守 Java 的开发者对协程的期待就不难理解了。 遗憾的是，Project Loom 未能合入 Java 15，那么按照其他特性的演进周期来看，在下一个 LTS（即 Java 17）发布时就算包含进来也不会是稳定特性。

当然，目前 JVM 平台的 5 门主流工业级语言（Java、Kotlin、Scala、Groovy、Clojure）中，只有 Kotlin 具备上述两个特性，欢迎来 Kotlin 中文站学习。

trait 与类型类（type class）分别是 Rust 与 Haskell 语言中的概念，用于特设多态（ad-hoc polymorphism）、函数式编程等方面。

值得一提的是虽然英文都是“trait”， Scala 的特质跟 Rust 的 trait ¹ 却并不相同。 Scala 的特质相当于 Kotlin 与 Java 8+ 的接口，能实现子类型多态；而 Rust 的 trait 更类似于 Swift 的协议与 Haskell 的类型类，能实现特设多态。简单来说，trait 应同时具备以下三项能力²：

1. 定义“接口”并可提供默认实现
2. 用作泛型约束
3. 给既有类型增加功能

Haskell 的类型类不仅同时具备这三项能力，还能定义函数式编程中非常重要的 Functor、Applicative、Monad 等。 当然这是废话，因为它们在 Haskell 中本来就是类型类😂。 实际上这也不是 trait 与类型类的差异，能否支持 Functor 等的关键在于语言的泛型参数能否支持类型构造器（或者说语言能否支持高阶类型）。

在 Kotlin 中寻求对应

在 Kotlin 中并没有同时具备这三项能力的对应，只有分别提供三项能力的特性。 其中 Kotlin 的接口同时具备前两项能力。

定义“接口”并可提供默认实现

例如，定义一个带有默认实现的接口：

interface WithDescription {
    val description: String get() = "The description of $this"
}

Kotlin 的接口中可以定义属性与方法，二者都可以有默认实现，简便起见，示例中用了具有默认实现的属性。它可以这么用：

class Foo: WithDescription {
    // Foo 类为 description 属性提供了自己的实现
    override val description = "This is a Foo object"
}

// 对象 Bar 的 description 属性采用默认实现
object Bar: WithDescription

println(Foo().description)
println(Bar.description)

在 Kotlin REPL 中执行会得到类似这样的输出：

This is a Foo object
The description of Line_7$Bar@5bf4764d

用作泛型约束

接下来还可以将之前定义的 WithDescription 接口用在泛型函数、泛型类或者其他泛型接口中作为泛型约束，例如：

fun <T : WithDescription> T.printDescription() = println(description)

在 REPL 中执行：

>>> Bar.printDescription()
The description of Line_7$Bar@5bf4764d

遗憾的是，在 Kotlin 中不能给既有类型（类或接口）实现新的接口，比如不能为 Boolean 或者 Iterable 实现 WithDescription。 即接口不具备第三项能力，因此它不是 trait/类型类。

给既有类型增加功能

在 Kotlin 中给既有类型增加功能的方式是扩展，可以给任何既有类型声明扩展函数与扩展属性。例如可以分别给 Int 与 String 实现二者间的乘法操作符函数：

operator fun Int.times(s: String) = s.repeat(this)

operator fun String.times(n: Int) = repeat(n)

于是就可以像 Python/Ruby 那样使用了：

>>> "Hello" * 3
res11: kotlin.String = HelloHelloHello
>>> 5 * "汉字"
res12: kotlin.String = 汉字汉字汉字汉字汉字

在 Kotlin 中“实现”trait/类型类

如上文所述，Kotlin 分别用接口与扩展两个不同特性提供了 trait/类型类的三项能力，因此在 Kotlin 中没有其直接对应。 那么如果把两个特性以某种方式结合起来，是不是就可以“实现”trait/类型类了？——还别说，真就可以！ Arrow 中的类型类就是这么实现的。

我们继续以 WithDescription 为例，不同的是，这回要这么声明：

interface WithDescription<T> {
    val T.description get() = "The description of $this"
}

这里利用了分发接收者可以子类化、扩展接收者静态解析的特性，可以为任何既有类型添加实现。 例如分别为 Char、String 实现如下：

object CharWithDescription : WithDescription<Char> {
    override val Char.description get() = "${this.category} $this"
}

// 采用默认实现
object StringWithDescription: WithDescription<String>

不过使用时会麻烦一点，需要借助 run() 或者 with() 这样的作用域函数在相应上下文中执行：

println(StringWithDescription.run { "hello".description })

with(CharWithDescription) {
    println('a'.description)
}

在 REPL 中执行的输出如下：

The description of hello
LOWERCASE_LETTER a

用作泛型约束也不成问题：

fun <T, Ctx : WithDescription<T>> Ctx.printDescription(t: T) = println(t.description)

StringWithDescription.run {
    CharWithDescription.run {
        printDescription("Kotlin")
        printDescription('①')
    }
}

这里实现的 printDescription() 与上文的函数签名不同，因为接收者类型用于实现基于作用域上下文的泛型约束了，这也是利用接口、扩展、子类型多态以及作用域函数这些特性来“实现”trait/类型类的关键所在。 当然，如果仍然希望目标类型（如例中的 Char、String）作为 printDescription 的接收者，只要将其接收者与参数互换即可：

fun <T, Ctx : WithDescription<T>> T.printDescription(ctx: Ctx) = ctx.run {
    println(description)
}

"hltj.me".printDescription(StringWithDescription)

上述两种方式中提供泛型约束的上下文要么占用了函数的扩展接收者、要么占用了函数参数。实际上还有一种方式——占用分发接收者，显然只要在 WithDescription 内声明 printDescription() 就可以了。 不过我们这里要假设 printDescription() 是自己定义的函数，而 WithDescription 是无法修改的既有类型，那么还能做到吗？——当然不成问题！只要用一个新接口继承 WithDescription 就可以了：

interface WithDescriptionAndItsPrinter<T>: WithDescription<T> {
    fun T.printDescription() = println(description)
}

object StringWithDescriptionAndItsPrinter: WithDescriptionAndItsPrinter<String>

object CharWithDescriptionAndItsPrinter:
    WithDescriptionAndItsPrinter<Char>, WithDescription<Char> by CharWithDescription

StringWithDescriptionAndItsPrinter.run {
   CharWithDescriptionAndItsPrinter.run {
        "hltj.me".printDescription()
        '★'.printDescription()
    }
}

将三种方式放一起对比会更直观：

// 方式 1
StringWithDescription.run {
    printDescription("hltj.me")
}

// 方式 2
"hltj.me".printDescription(StringWithDescription)

// 方式 3
interface WithDescriptionAndItsPrinter { /*……*/ }
object StringWithDescriptionAndItsPrinter: WithDescriptionAndItsPrinter<String>
StringWithDescriptionAndItsPrinter.run {
    "hltj.me".printDescription()
}

第三种方式的优点是提供泛型约束的上下文既不占用扩展接收者也不占用参数，但其代价是需要为每个用到的目标类型（如例中的 Char、String）提供新接口（如例中的 WithDescriptionAndItsPrinter<T>）的相应实现，并且依然需要借助作用域函数 run() 或 with()。 因此通常采用前两种方式即可，但是如果要自定义操作符函数或者中缀函数时就只能采用第三种方式了，例如：

interface DescriptionMultiplier<T>: WithDescription<T> {
    infix fun T.rep(n: Int) = (1..n).joinToString { description }

    operator fun T.times(n: Int) = this rep n
}

object CharDescriptionMultiplier:
    DescriptionMultiplier<Char>, WithDescription<Char> by CharWithDescription

println(object : DescriptionMultiplier<String> {}.run { "hltj.me" rep 2 })

println(CharDescriptionMultiplier.run { 'A' * 3 })

在 REPL 中执行的输出为：

The description of hltj.me, The description of hltj.me
UPPERCASE_LETTER A, UPPERCASE_LETTER A, UPPERCASE_LETTER A

扩展与成员的优先级

我们知道，在 Kotlin 中扩展与成员冲突时总是取成员。 但是在使用基于作用域上下文的泛型约束时却并非如此，例如：

interface WithLength<T> {
    val T.length: Int
}

object StringWithFakeLength: WithLength<String> {
    override val String.length get() = 128
}

fun <T, U: WithLength<T>> U.printLength(t: T) = println(t.length)

StringWithFakeLength.run {
    printLength("hltj.me")
}

在 REPL 中运行输出是 128，表明 printLenth() 取到的 length 是 StringWithFakeLength 中定义的扩展属性而不是 String 自身的属性。因此使用时需要特别注意。 唯有 Any 的三个成员 toString()、hashCode()、equals() 会始终调用成员函数，即便在泛型约束上下文中声明了具有相同签名的扩展函数也是一样。

“实现”Functor 等

按照上文介绍的方式，我们可以轻松实现 Show、Eq、Ord 等简单类型类，无需赘述。 但是如果要实现 Functor、Applicative、Monad 等却会遇到问题。 以 Functor 为例，按说要这么定义：

interface Functor<C<*>> {
    fun <T, R> C<T>.fmap(f: (T) -> R): C<T>
}

但遗憾的是上述代码无法通过编译，因为 Kotlin 目前不支持高阶类型，在泛型参数中用 C<*> 表示类型构造器只是假想的语法 。 因此，需要有一种方式来变通。按 Arrow 的方式引入 Kind 接口来表示：

interface Kind<out F, out A>

interface Functor<F> {
    fun <T, R> Kind<F, T>.fmap(f: (T) -> R): Kind<F, R>
}

然后写一个标记类，让具体类型作为 Kind<标记类, T> 的实现类。再定义一个由 Kind<标记类, T> 向具体类型转换的扩展函数 fix()，以便在具体实现中使用。 例如：

class ForMaybe private constructor()

sealed class Maybe<out T> : Kind<ForMaybe, T> {
    object `Nothing#` : Maybe<Nothing>() {
        override fun toString(): String = "Nothing#"
    }
    data class Just<out T>(val value: T) : Maybe<T>()
}

fun <T> Kind<ForMaybe, T>.fix(): Maybe<T> = this as Maybe<T>

这样就可以为 Maybe 实现 Functor<ForMaybe> 了：

object MaybeFunctor : Functor<ForMaybe> {
    override fun <T, R> Kind<ForMaybe, T>.fmap(f: (T) -> R): Maybe<R> = when (val maybe = fix()) {
        is Maybe.Just -> Maybe.Just(f(maybe.value))
        else -> Maybe.`Nothing#`
    }
}

fun main() = with(MaybeFunctor) {
    println(Maybe.Just(5).fmap { it + 1 })
    println(Maybe.`Nothing#`.fmap { x: Int -> x + 1 })
}

可以看出这种实现方式会有明显的局限性：只能为 Arrow 中定义的类型或者按照 Arrow 方式实现的既有类型实现 Functor、Applicative、Monad 等接受类型构造器作为泛型参数的“类型类”。 好在 Arrow 已经自带了大量有用的类型，很多场景都够用。

需要注意的是这段代码无法在当前版本（1.3.61）的 Kotlin REPL 中运行，需要放在普通的 Kotlin 文件中编译运行。

Arrow

Arrow（按其官网写作 Λrrow）是 Kotlin 标准库的函数式“伴侣”。目前主要以下四套件：

• Arrow Core 提供了核心的数据类型与类型类。
• Arrow FX 是函数式副作用库，提供了 do-表示法/Monad 推导风格的 DSL。
• Arrow Optics 用于在 Kotlin 中处理不可变数据模型。
• Arrow Meta 是 Kotlin 编译器与 IDE 的函数式“伴侣”。

此外还有若干套件/特性还在孵化中。 关于 Arrow 整体与模式的介绍也在 Arrow Core 的文档中，其中 Functional Programming Glossary 提供了一些使用 Arrow 进行函数式编程的背景知识可供参考。

一点意外

在尝试写这些示例时意外发现了一个会导致当前版本的 Kotlin JVM 编译器抛异常的 bug，最小重现代码如下：

interface WithIntId<T> {
    val T.intId get() = 1
}

object BooleanWithIntId : WithIntId<Boolean>

val x = BooleanWithIntId.run {
    true.intId
}

只影响 Kotlin JVM 编译器，Kotlin JS 与 Kotlin Native 都不存在这个问题。 查了下 YouTrack，看起来是个已知 bug。 不过文中的其他示例代码都能正常编译运行，尽可放心。

问题与解决方案

传统编程语言中往往使用空值（null 或者 None、nil 等）来表达可选值，可谓简单粗暴。 因为这样一来，就需要在每一处使用的地方判断相应的值是否为空，一旦疏忽大意就可能导致程序出错甚至崩溃。 不仅如此，正如著名的《十亿美元的错误》与《计算机科学中的最严重错误》所说，传统空值还引入了一系列其他问题：破坏了类型系统、易与空容器混为一谈、表意模凌两可、难以调试、不便同语言的其他特性结合使用等。

因此，现代编程语言基本都会避免使用传统空值，而采用更安全的方式来表达可选值，具体方式主要有两种：

1. 受限的空值：Kotlin、Swift、Hack、C# 8+ 等。
2. 可选值类型：Haskell、Rust、Julia、OCaml、Swift、F#、Scala、Java 8+、C++17+ 等。

你没看错，Swift 在两边都站队了。这倒并不是它采用了两种不同的机制，相反，它在一致的底层机制基础上，同时兼容两种上层语法。

另外 F#、Scala、Java 8+、C++ 17+ 实际上处于灰色地带，它们虽然推荐使用可选值类型，却也支持传统空值。

值得一提的是，无论采用哪种方式，其安全性都是由类型系统来保障的。 虽然这并不仅限于静态类型语言（Hack 与 Julia 都是动态类型语言），不过确实需要一定程度的静态类型支持，这也从侧面反映了现代编程语言的静态类型趋势。

历史包袱

采用受限空值的编程语言与处于灰色地带的编程语言一般都存在历史包袱。

采用受限空值的语言可能都与历史包袱有关：Kotlin 中有 null 因为 Java 中有，Hack 中有 null 因为 PHP 中有，Swift 中有 nil 因为 Objective-C 中有，C# 8+ 中有 null 是因为 C# 的历史版本中有且需要与 .Net 平台其他语言互操作。

处于灰色地带的 F#、Scala、Java 8+、C++ 17+ 同样有历史包袱，因为需要与 .Net/JVM 平台的其他语言互操作或者要兼容本语言的旧版本。

但是两队语言做了不同的抉择：一队采用受限的空值取代了传统空值；另一队引入了可选值类型的同时，却还保留传统空值。 于是后面这队语言虽有安全的方式，却也无法摆脱传统空值的纠缠。 Java 8 与 C++ 17 为了兼容历史版本或是无奈之选，但是如果历史重新给 F# 与 Scala 选择机会的话，会不会采用 Swift 的方案更好一些？

这里特别值得一提的是，C# 8 的选择给了大家一个启示： 即便曾经做了错误的设计，仍然可以重回正轨，就看语言的后续版本有没有壮士断腕的勇气。

受限的空值

在采用受限的空值来表达可选值的编程语言中，对空值的使用有以下限制：

1. 语言中严格区分可空类型与非空类型，不能直接将可空值用于只接受非空值的地方。
2. 语言中通过特定语法访问可空类型对象的成员，也需要特定语法由可空值得到非空值。

区分可空与非空类型

Kotlin、Swift、Hack、C# 8+¹ 都严格区分可空类型与非空类型，并且类型都默认非空，对于可空类型也都采用加注 ? 的方式来表达（只是 Hack 放在类型名前，Kotlin、Swift 与 C# 放在类型名后）。我们看些具体的示例：

// Kotlin
val a: Int = 1 // OK
val b: Int = null // 错误，b 不接受空值
val c: Int? = null // OK，c 是可空类型

val d: Int = a // OK
val e: Int? = a // OK，非空表达式可以赋给可空变量
val f: Int = c // 错误，f 不接受可空表达式赋值
val g: Int? = c // OK
val h = c // OK，h 的类型会推断为 Int?

Swift 版与之非常类似，只需将 val 替换为 let、null 替换为 nil 即可。 Hack 语法与它们差异大些、并且需要采用函数形式来表达上述示例，但其相似性还是很明显的：

// Hack
function a(): int { return 1; }
function b(): int { return null; } // 错误
function c(): ?int { return null; }
function d(): int { return a(); }
function e(): ?int { return a(); }
function f(): int { return c(); } // 错误
function g(): ?int { return c(); }
function h() { return c(); }

除了变量声明与赋值、函数返回值之外，这几门语言对函数传参、数学运算等各种表达式都会严格区分可空与非空类型。

可空性传播

在采用受限空值的编程语言中，无法直接访问可空类型对象的成员，需要使用特殊语法。在 Kotlin、Swift 与 C# 8+ 中使用 ?. 语法，在 Hack 中使用 ?-> 语法。例如输出一个可空字符串的长度：

Kotlin 代码，输出是 12：

val hello: String? = "Hello, World"
println(hello?.length)
hello?.length.plus(10) // 错误，可空值不能直接调用方法

Swift 代码，输出是 Optional(12)：

let hello: String? = "Hello, World"
print(hello?.count)
hello?.count + 10 // 错误，可空值不能用于算术运算

Hack 代码有些复杂，因为内置字符串值不是对象，所以需要模拟出一个对象，其输出是 12:

class String0 {
    private string $s;
    public function __construct(string $s) {
        $this->s = $s;
    }
    public function length(): int {
        return strlen($this->s);
    }
}

function hello(): ?String0 {
    return new String0("Hello, World");
}

function printLength(?String0 $s) {
   echo $s?->length(), "\n";
}

printLength(new String0("Hello, World"));

function foo(): int { return hello()?->length(); } // 错误，函数签名要求非空返回值

Swift 输出的是 Optional(12)，它明确表明这是一个 Int? 值。Kotlin 与 Hack 虽然直接输出了数字，但其值同样是可空整型，不能用于只接受非空整数的地方。?./?->的求值逻辑为：

1. 如果对象非空，那么访问相应成员。
2. 如果对象为空，返回空。
3. 返回类型为可空类型。

以 Kotlin 为例，虽然 String 的 length 属性是非空成员，但因为 hello 是可空的，进而导致 hello?.length 也是可空的，因此如需继续调用 plus 也要使用 ?. 语法：

>>> hello?.length?.plus(10)
22

并且这一表达式依然是可空的，因此如果还有后续成员访问，就还需使用 ?. 语法：

>>> hello?.length?.plus(10)?.times(1.2)?.toLong()
26

可空性就像病毒一样感染了整个调用链条，并且会继续传播下去。在 C# 8+ 中也是如此；在 Hack 中与此类似，只是使用 ?-> 语法。不过 Swift 的语法与它们不同，对于上述情况，后续链条中用 . 即可，但是最终结果仍然是可空值：

3> let a = hello?.utf8.count.advanced(by: 10).distance(to: 100)
a: Int? = 78

Swift 中只有后续成员的返回值本身也是可空类型时才需要再次使用 ?.，参见其官网介绍：

if let johnsStreet = john.residence?.address?.street {
    print("John's street name is \(johnsStreet).")
} else {
    print("Unable to retrieve the address.")
}

当然，在 Kotlin 中也可以通过高阶函数 let 来简化多级 ?. 的语法，进而达到接近 Swift 的效果：

>>> hello?.let{ it.length.plus(10).times(1.2).toLong() }
26

此外 Swift 与 C# 还支持可空对象的索引访问（?[]）语法，C# 8 还引入了空接合赋值操作符（??=）。

可空值用于常规函数

如果不是访问成员，而是用于普通函数，例如将上述链式调用的结果传给 sin 函数并输出其结果，该如何实现呢？ 这在 Kotlin 与 Swift 中分别有不同的语法：

Kotlin 代码：

>>> hello?.length?.plus(10)?.times(1.2)?.toLong()?.let {
...     println(Math.sin(it * 1.0))
... }
0.7625584504796028

Swift 代码：

4> import Foundation
5> if let a = hello?.utf8.count.advanced(by: 10).distance(to: 100) {
6.     print(sin(Double(a)))
7. }
0.513978455987535

目前在 Hack 中没有类似语法，可以通过更通用的由可空表达式获得非空值的方式实现。

由可空表达式获得非空值

这里只讨论安全获得非空值的方式。由可空表达式安全地获得非空值还需要提供一个默认值，这样就一定能够取得非空值：当表达式求值结果非空时取求值结果，否则取默认值。这在 Kotlin 中通过 Elvis 操作符（?:）来实现，在 Swift、Hack 与 C# 中通过空接合操作符（??）来实现。

现在有没有觉得受限空值与问号（?）结下了不解之缘 :P

Kotlin 示例：

>>> val hello: String? = "Hello, World"
>>> val len: Int = hello?.length ?: 0
>>> ((hello?.length ?: 0) + 10) * 1.2
26.4
>>> val hello: String? = null
>>> ((hello?.length ?: 0) + 10) * 1.2
12.0

Swift 示例：

  1> let hello: String? = "Hello, World" 
hello: String? = "Hello, World"
  2> let len: Int = hello?.count ?? 0 
len: Int = 12
  3> 100 - ((hello?.count ?? 0) + 10)
$R0: Int = 78
  4> let hello: String? = nil
hello: String? = nil
  5> 100 - ((hello?.count ?? 0) + 10) 
$R1: Int = 90

可选值类型

更多的现代编程语言都是采用可选值类型的方式。在这些语言中，都是通过一种专门的包装类型来表达可选值。 下表列举了一些语言中可选字符串的类型以及有无值的字面值表示法：

包装后的类型与原类型明显不同，因此无法当作原类型来用。那么应该如何使用呢？

显式判断与模式匹配

最简单的使用方式是显式判断，例如求一个可选字符串的长度（Julia）：

julia> lengthOfOptionalString(us::Union{Some{String}, Nothing}) =
           if us === nothing
               0
           else
               length(us.value)
           end
lengthOfOptionalString (generic function with 1 method)

julia> lengthOfOptionalString(nothing)
0

julia> lengthOfOptionalString(Some("Hello"))
5

如果用 C++ 或者 Java 实现会与之非常相似。而对于上文所列的其他使用可选值类型的语言，都可以采用模式匹配的方式实现类似功能。例如（Haskell）：

ghci > :{
ghci | lengthOfMaybeString:: Maybe String -> Int
ghci | lengthOfMaybeString Nothing = 0
ghci | lengthOfMaybeString (Just s) = length s
ghci | :}
ghci > lengthOfMaybeString Nothing
0
ghci > lengthOfMaybeString (Just "Hello")
5

在 Haskell 中只需在声明函数时对 Maybe String 类型参数的不同模式 Nothing 与 Just s 分别编写实现即可。函数调用时 Haskell 会根据实参类型自动匹配到相应实现。

实际上，Julia 虽然没有在语言级支持完整的模式匹配，但是在 Julia 中可以通过泛型函数实现与上述 Haskell 代码类似的写法：

julia> lengthOfOptionalString(nothing) = 0
lengthOfOptionalString (generic function with 1 method)

julia> lengthOfOptionalString(ss::Some{String}) = length(ss.value)
lengthOfOptionalString (generic function with 2 methods)

julia> lengthOfOptionalString(nothing)
0

julia> lengthOfOptionalString(Some("Hello"))
5

我们再看一下 Rust 的写法：

irust> let a: Option<&str> = None;
()
irust> let b: Option<&str> = Some("Hello");
()
irust> match a { None => 0, Some(ref s) => s.len() }
0
irust> match b { None => 0, Some(ref s) => s.len() }
5

这段代码乍一看跟传统语言的 switch-case 很类似，但实际上要强大的多。 上述代码中的 Some(ref s) => 含 s 的表达式 就是传统 switch-case 无法支持的。对于匹配到模式 Some(ref s) 的 Option，Rust 能够自动提取模式中对应的 s，并用于后续处理。

我们可以通过显式判断或模式匹配来处理可选值类型，但通常并不这么做，因为还有更便捷的方式。

函数式方式

以函数式方式实现求一个可选字符串的长度的代码，可以这样写（Java）：

jshell> int lengthOfOptionalString(Optional<String> opStr) {
   ...>     return opStr.map(String::length).orElse(0);
   ...> }
   ...>
| 已创建 方法 lengthOfOptionalString(Optional<String>)

jshell> lengthOfOptionalString(Optional.empty())
$2 ==> 0

jshell> lengthOfOptionalString(Optional.of("Hello"))
$3 ==> 5

这里用到了 Optional<T> 的两个方法：map() 与 orElse()。

其中 Optional<T>.map() 接受一个函数式接口参数 mapper（可以传入 lambda 表达式或者方法引用），如果可选值无值，那么直接返回 Optional.empty()；而如果有值，那么返回对其值调用 mapper 所得结果的 Optional<U> 包装。

Optional<U>.orElse() 接受一个 U 类型的参数 default，如果可选值有值则返回其值，如果无值返回 default，因此通过 Optional<U>.orElse() 总能得到一个 U 类型的值。

实际上，可选值类型是 Functor、Applicative、Monad，上述 Optional.map() 相当于 Haskell 中 Functor 的 fmap/<$>。此外，常用的还有相当于 Monad 的 >>= 的函数，如 Java 的 Optional.flatMap()、Rust 的 Option::and_then()、OCaml 4.08+/F# 的 Option.bind 等。我们看一个 F# 的示例——对一个整数可选值求余：

> let (%?) a b =
-     match b with
-     | 0 -> None
-     | _ -> Some (a % b);;
val ( %? ) : a:int -> b:int -> int option

> 18 %? 5;;
val it : int option = Some 3

> 18 %? 0;;
val it : int option = None

> Option.map ((%?) 18) (Some 5);;
val it : int option option = Some (Some 3)

> Option.map ((%?) 18) (Some 0);;
val it : int option option = Some None

> Option.map ((%?) 18) None;;
val it : int option option = None

> Option.bind ((%?) 18) (Some 5);;
val it : int option = Some 3

> Option.bind ((%?) 18) (Some 0);;
val it : int option = None

> Option.bind ((%?) 18) None;;
val it : int option = None

上述代码只需将 % 运算符替换为 mod 并交换 Option.bind 两个参数的位置即可用于 OCaml 4.08+。

示例中首先定义了一个安全求余运算符 %?，当除数为 0 时它返回 None，否则返回 Some 余数。 %? 只接受整数作除数，如需将其应用到 int option 可以借助 Option.map，但是这样得到的结果是嵌套的 option（即 int option option）。 有没有可能直接得到单层的 int option 呢？——这就需要 Option.bind 大显身手了，如例中所示。

注：上文所列的其他使用可选值类型的语言的标准库没有为可选值类型实现类似 Haskell 中 Applicative 的 liftA2/<*> 的函数，可选用第三方实现或者参考 Applicative 文档或 Kotlin 版图解 Functor、Applicative 与 Monad 自行实现。

综合示例

我们看一个 Kotlin 心印中的示例：实现一个给客户发消息的函数，其中客户、消息、客户的个人信息字段、个人信息的邮箱地址字段都可能无值。 用传统 Java 代码实现如下所示：

public void sendMessageToClient(
    @Nullable Client client, @Nullable String message, @NotNull Mailer mailer
) {
    if (client == null || message == null) return;

    PersonalInfo personalInfo = client.getPersonalInfo();
    if (personalInfo == null) return;

    String email = personalInfo.getEmail();
    if (email == null) return;

    mailer.sendMessage(email, message);
}

上述代码使用了卫语句，可以说已经是质量很高的传统 Java 代码了。 但由于对其中每处可空值都需要判空，有意义的代码与判空代码各有三行，可以说一半的代码都浪费在了毫无业务价值而又不得不做的事情上了。 同时该代码中有 4 个分支、4 个出口，代码虽不多，流程却已略显复杂。 而如果使用 Java 8 的 Optional，就可以流畅很多：

public void sendMessageToClient(
    Optional<Client> client, Optional<String> message, @NotNull Mailer mailer
) {
    message.ifPresent(
            message1 -> client
                    .flatMap(Client::getPersonalInfo)
                    .flatMap(PersonalInfo::getEmail)
                    .ifPresent(
                        email -> mailer.sendMessage(email, message1)
                    )
    );
}

在 Swift 语言中，可以综合使用受限空值与可选值类型的语法，代码会更简洁一些：

func sendMessageToClient(client: Client?, message: String?, mailer: Mailer) {
    message.map {
        message1 in client?.personalInfo?.email.map {
            email in mailer.sendMessage(email, message1)
        }
    }
}

在 Kotlin 语言中，可以综合使用受限空值与 return 表达式，代码会非常简洁：

fun sendMessageToClient(client: Client?, message: String?, mailer: Mailer) {
    mailer.sendMessage(client?.personalInfo?.email ?: return, message ?: return)
}

综述

传统空值会带来一系列问题，为避免这些问题，现代编程语言通常采用受限的空值或者可选值类型来表达可选值。 这些现代编程语言不仅通过类型系统确保了可选值的安全性，还提供了各种相对便利的使用方式来提升可选值的易用性。

修订记录

2020-03-27：

• 补充 OCaml 4.08+ 的 Option.bind 相关内容
• 增加部分 C# 8+ 相关内容

2025-10-19：

• 修正手误
• 更新 Swift 多层 Optional 链式调用文档链接

但是在 64 位 Windows 中没有 NTVDM 与 WOW。

于是有人（leecher1337）开发了 NTVDMx64——可以在 64 位 Windows 环境中运行的 NTVDM。

https://github.com/leecher1337/ntvdmx64

不过它可能会对系统有些影响，在该项目的 README 中提到了可能会导致一些 DPMI 程序崩溃。README 中还解释了为什么已经有 DOSBox 了还要移植 NTVDM。

而 otya 的 WineVDM 则更进一步，不仅可以在 64 位的 Windows 中运行 DOS 程序，还可以运行 16 位的 Windows 程序。

https://github.com/otya128/winevdm

下图是使用 WineVDM 在 64 位 Windows 10 中运行 Windows 3.2 的计算器与时钟的截图：

这个 WineVDM 是 Wine 项目中同名程序的增强版（在其 README 中也提到了），还可以运行 DOS 程序。

值得一提的是 WineVDM 本身是 32 位程序，不过能在 64 位 Windows 中正常运行。 既然是 32 位程序，那当然可以在 32 位环境运行了，只是对于 32 位 Microsoft Windows 来说并不需要，因为已经有 NTVDM 与 WOW 可以运行 DOS 程序及 16 位 Windows 程序。 但是在 ReactOS 中就能派上用场了：

本文已获得翻译授权，译自 Standardizing WASI: A system interface to run WebAssembly outside the web，由作者 Lin Clark 于当地时间 2019-03-27 发布。

今天（当地时间 2019-03-27），我们宣布开始进行一项新的标准化工作——WASI，WebAssembly 系统接口（WebAssembly System Interface）。

起因（Why）： 开发人员开始将 WebAssembly 向浏览器之外推进，因为它提供了一种快速、可扩展、安全的方式来在所有计算机上运行相同的代码。

但是我们尚未建立一个坚实的基础。 浏览器之外的代码需要一种与系统交互的方式——系统接口。 而 WebAssembly 平台还没有系统接口。

事物（What）： WebAssembly 是概念机的汇编语言，而不是物理机的汇编语言。 这就是它可以在各种不同计算机体系结构上运行的原因。

正因为 WebAssembly 是概念机的汇编语言，所以 WebAssembly 需要一个概念操作系统的系统接口，而不是任何单一操作系统的系统接口。 这样，它就可以在所有不同操作系统中运行。

这就是 WASI——WebAssembly 平台的系统接口。

我们的目标是创建一个系统接口，它会成为 WebAssembly 的真正伴侣，并经受起时间的考验。 这意味着坚持 WebAssembly 的关键原则——可移植性与安全性。

人物（Who）： 我们正在组建一个 WebAssembly 的一个子工作组，专注于 WASI 标准化。 我们已经聚集了一些志同道合的合作伙伴，并且还在寻找更多伙伴加入。

以下是我们、我们的合作伙伴与支持者认为这很重要的一些原因：

Sean White，Mozilla 的首席研发官

“WebAssembly 已经在改变 web 给人们带来新的引人入胜的内容的方式，并使开发者与创作者能在 web 上尽显身手。 到目前为止，已经通过浏览器实现了，不过有了 WASI，我们可以将 WebAssembly 与 web 的益处传递给更多用户、更多场合、更多设备，以及作为更多体验的一部分。”

Tyler McMullen，Fastly 的 CTO

“我们将 WebAssembly 带到浏览器之外，在我们的边缘云中作为快速、安全地执行代码的平台。 虽然我们的边缘与浏览器之间存在环境差异，但是 WASI 意味着 WebAssembly 开发者无需将代码移植到每个不同的平台。”

Myles Borins，Node 技术指导委员会主任

“WebAssembly 可以解决 Node 中最大的问题之一——如何获得接近原生速度，并像使用原生模块一样复用其他语言（如 C 与 C++）编写的代码，同时仍保持可移植性与安全性。 标准化这个系统接口是实现这一目标的第一步。”

Laurie Voss，npm 的联合创始人

“npm 极为感兴趣的是，WebAssembly 潜在具有扩展 npm 生态系统、并同时极大地简化在服务端 JavaScript 应用程序中运行原生代码过程的能力。 我们期待这个过程的结果。”

所以说这是个大新闻！🎉

WASI 目前有三份实现:

• wasmtime，Mozilla 的 WebAssembly 运行时
• Lucet，Fastly 的 WebAssembly 运行时
• 浏览器垫片（polyfill）

（如果你能访问 YouTube）可以在这个视频中看个 WASI 实战：

如果你希望了解关于这个系统接口应该如何工作的提案的更多信息，请继续阅读。

系统接口是什么？

很多人说像 C 这样的语言可以直接访问系统资源。 但事实并非如此。

这些语言无法直接在大多数系统上进行打开或创建文件等操作。 为什么不能呢？

因为这些系统资源（诸如文件、内存以及网络连接）对于稳定性与安全性来说太重要了。

如果一个程序无意中搅乱了另外一个程序的资源，那么它可能会使另一个程序崩溃。 更糟的是，如果一个程序（或用户）故意干扰另一个程序的资源，那么它可能会窃取敏感数据。

因此，我们需要一种方式来控制哪些程序与用户可以访问哪些资源。 人们很早就发现了这一点，并想出了一个提供这种控制的方式：保护环安全。

有了保护环安全，操作系统基本上在系统资源外围设置了保护屏障。 这就是内核。 内核是唯一可以进行创建新文件、打开文件或者打开网络连接等操作的地方。

用户的程序在称之为用户模式的内核以外运行。 如果程序想做打开文件这样的事，它必须请求内核为它打开。

这就是系统调用的概念所在。 当程序需要让内核执行这其中某一项操作时，它会使用系统调用来请求。 这让内核有机会找出是哪个用户在请求。 然后就可以在打开文件之前分辨该用户是否有权访问该文件。

在大多数设备上，这是代码可以访问系统资源的唯一方式——通过系统调用。

操作系统让系统调用可用。 但是如果每个操作系统都有自身的系统调用，那岂不是需要为每个操作系统编写不同版本的代码？ 幸运的是，并不用。

这个问题是如何解决的呢？——抽象。

大多数语言都提供了标准库。 在编码时，程序员并不需要知道他们所面向的系统。 他们只是使用相应接口。

然后在编译时，工具链会根据所面向的目标系统来选择使用该接口的哪个实现。 这个实现会使用操作系统 API 中的函数，因此它是平台相关的。

这就是系统接口的用武之地。 例如，为 Windows 计算机编译的 printf 可以使用 Windows API 与该计算机进行交互。 而为 Mac 或者 Linux 编译，则会改用 POSIX。

然而这却给 WebAssembly 带来了一个问题。

对于 WebAssembly 来说，即使在编译时也无从知晓所面向的是哪种操作系统。 因此，无法在标准库的 WebAssembly 实现中使用任何单一操作系统的系统接口。

我之前说过 WebAssembly 是一种概念机的汇编语言，而不是真实计算机的汇编语言。 同样，WebAssembly 也需要一套概念操作系统（而不是真实操作系统）的系统接口。

不过已经存在可以在浏览器之外运行 WebAssembly 的运行时了，即便没有这个系统接口。 他们是怎么做到的呢？我们来看一看。

如今 WebAssembly 是如何在浏览器之外运行的？

生成 WebAssembly 的第一个工具是 Emscripten。 它在 web 上模拟一个特定操作系统的系统接口 POSIX。 这意味着程序员可以使用 C 标准库（libc）中的函数。

为此，Emscripten 创建了自己的 libc 实现。 这个实现分为两部分——一部分编译成 WebAssembly 模块，另一部分用 JS 胶水代码实现。 这个 JS 胶水层会调用浏览器，进而与操作系统交互。

大多数早期的 WebAssembly 代码都是使用 Emscripten 编译的。 因此，当人们开始想在没有浏览器的情况下运行 WebAssembly 代码时，他们会从让 Emscripten 所编译的代码能运行入手。

于是，这些运行时需要为 JS 胶水代码中的所有函数创建自身的实现。

不过，这里有个问题。 这个 JS 胶水代码所提供的接口并没有设计成标准接口，甚至并非面向公众的接口。 这并不是它所解决的问题。

例如，对于一个在设计成公开接口的 API 中名为 read 的函数，其 JS 胶水代码使用的是 _system3(which, varargs)。

第一个参数 which 是一个整数，它始终与名称中的数字相同（在本例中是 3）。

第二个参数 varargs 是用到的参数。 它之所以称为 varargs，是因为可以有可变数量的参数。 但是 WebAssembly 并没有提供将可变数量参数传给函数的方式。 于是，这些参数通过线性内存传递。 这不是类型安全的做法，而且也比使用寄存器传递参数（如果可能的话）慢。

对于在浏览器中运行 Emscripten 来说，这没有问题。 但是现在运行时将其视为事实上的标准，实现了自身版本的 JS 胶水代码。 他们是在模拟 POSIX 仿真层的内部细节。

这意味着他们正在重新实现那些对于 Emscripten 的约束有意义的选择（例如将参数作为堆中值传递），即便这些约束并不适于他们的环境。

如果我们要构建一个持续数十年的 WebAssembly 生态系统，我们就需要坚实的基础。 这意味着我们的事实标准不能是仿真的仿真。

不过我们应该采用什么原则呢？

WebAssembly 系统接口需要坚持什么原则？

有两项重要的原则已经融入到 WebAssembly 中：

• 可移植性
• 安全性

当我们转向浏览器之外的应用场景时，我们需要坚持这些关键原则。

实际上，POSIX 与 Unix 的安全访问控制方式并没有帮我们达到目的。 我们来看下它们的不足之处。

可移植性

POSIX 提供了源代码级的可移植性。 相同的源代码可以与不同版本的 libc 一起编译来面向不同的计算机。

但是 WebAssembly 需要超越它一步。 我们需要能够编译一次就能在一系列不同的计算机上运行。 我们需要可移植的二进制文件。

这种可移植性让用户分发代码更容易。

例如，Node 的原生模块如果是用 WebAssembly 编写的，那么当用户安装带有原生模块的应用时就不需要运行 node-gyp 了，开发人员也无需配置并分发几十个二进制文件了。

安全性

当一行代码请求操作系统执行某些输入或输出时，操作系统需要确定该代码所请求的操作是否安全。

操作系统通常使用基于所有权与组的访问控制来处理这个问题。

例如，程序可能会请求操作系统打开一个文件。 一个用户具有他有权访问的特定一组文件。

当该用户启动程序时，该程序代表用户运行。 如果这个用户有权访问某文件（要么因为他是所有者，要么因为他在有权访问的组里），那么该程序也能访问。

这在用户之间提供了保护。 在早期操作系统开发出来时很有意义。 系统通常是多用户的，而管理员控制安装什么软件。 所以最突出的威胁是其他用户偷看你的文件。

情况已经变了。 现在系统通常是单个用户，但是他们会运行引入了许多未知可信度的其他第三方代码的代码。 现在最大的威胁是你自己运行的代码会对你不利。

例如，假设你在应用程序中使用的库来了一个新的维护者（在开源项目中经常发生）。 该维护者可能会对你的兴趣很上心……也可能是个坏人。 如果这些代码有权在你的系统上做任何事（例如，打开你的任何文件并通过网络发送出去），那么其代码会造成很大的损害。

这就是为什么使用可以直接与系统交互的第三方库可能是危险的。

WebAssembly 实现安全性的方式与此不同。 WebAssembly 采用了沙箱。

这意味着代码不能直接与操作系统交互。 那么它是如何利用系统资源的呢？ 宿主机（可能是浏览器，也可能是 wasm 运行时）将函数放入代码可以使用的沙箱中。

这意味着宿主机可以逐一限制每个程序可以做什么。 它并不是仅仅让程序代表用户、使用该用户的完整权限调用任何系统调用。

只是拥有沙箱机制并不会使系统本身变安全（宿主机仍然可以将所有能力都放入到沙箱中，若是这种情况则并没有变好），不过它至少让宿主机能够选择创建更安全的系统。

在我们设计的任何系统接口中，我们都需要坚持这两项原则。 可移植性让开发与分发软件更容易，而为宿主机提供保护自身或用户的工具更是绝对必需。

这个系统接口应该是什么样的？

鉴于这两项关键原则，WebAssembly 系统接口应该设计成什么样的？

这正是我们要通过标准化过程得出的成果。 不过我们确实有个提案要启动：

• 创建模块化的一组标准接口
• 开始标准化最基本的模块 wasi-core

wasi-core 里会有什么？

wasi-core 会包含所有程序都需要的基本接口。 它会覆盖与 POSIX 近乎相同的领域，包括诸如文件、网络连接、时钟以及随机数。

并且其中很多会采用与 POSIX 非常类似的方式。 例如，它会使用 POSIX 的面向文件的方式，其中有诸如 open、close、read 以及 write 这样的系统调用，而所有其他内容基本都是在此之上提供的扩充。

不过 wasi-core 并不会覆盖所有 POSIX 的内容。 例如，进程概念并没有清晰映射到 WebAssembly 上。 更进一步，让每个 WebAssembly 引擎都需要支持像 fork 这样的进程操作并无意义。 当然我们也希望标准化 fork 成为可能。

这就模块化方式的用武之地。 通过这种方式，我们可以获得良好的标准化覆盖率，同时仍然让一些平台能够只使用对其有意义的 WASI 部分。

像 Rust 这样的语言会直接在其标准库中使用 wasi-core。 例如，Rust 的 open 在编译到 WebAssembly 时会通过调用 __wasi_path_open 来实现。

对于 C 与 C++，我们创建了一个 wasi-sysroot，它根据 wasi-core 实现了 libc。

我们期望像 Clang 这样的编译器准备好与 WASI API 交互，并完成像 Rust 编译器与 Emscripten 这样的工具链，将 WASI 作为其系统实现的一部分。

用户代码如何调用这些 WASI 函数？

运行用户代码的运行时会将 wasi-core 函数作为导入传入。

这为我们提供了可移植性，因为每个宿主机都可以有专为其平台（从像 Mozilla 的 wasmtime 与 Fastly 的 Lucet，到 Node 乃至浏览器）编写的自身的 wasi-core 实现。

它还为我们提供了沙箱，因为宿主机可以逐个程序选择哪些 wasi-core 函数可以传入（即允许哪些系统调用）。 这保持了安全性。

WASI 为我们提供了进一步扩展这种安全性的方式。 它从基于能力的安全性中引入了更多概念。

传统方式中，如果代码需要打开一个文件，那么它会用一个路径名字符串调用 open。 然后操作系统检验该代码是否有权限（基于启动该程序的用户）。

对于 WASI，调用一个需要访问文件的函数必须传入一个附加了权限的文件描述符。 可以是用于该文件自身的描述符，也可以是用于包含该文件的目录的描述符。

这样，就不会有随机请求打开 /etc/passwd 的代码。 相反，代码只能对传给它的目录进行操作。

这让为沙箱中的代码安全地提供更多不同系统调用的访问控制成为可能——因为这些系统调用的能力是受限的。

并且这是发生在逐个模块基础上的。 默认情况下，模块没有对任何文件描述符的访问权限。 但是如果一个模块中的代码拥有文件描述符，那么它可以选择将该文件描述符传给其他模块中它所调用的函数。 也可以创建更受限版本的文件描述符来传给其他函数。

因此运行时可以将应用可用的文件描述符传到顶层代码，然后这些文件描述符就可以按需传播到系统的其余部分。

这让 WebAssembly 更接近最小权限原则——一个模块只能访问完成其工作所需的确切资源。

这些概念来自于能力导向系统（capability-oriented systems），例如 CloudABI 与 Capsicum。 能力导向系统的一个问题是通常很难向它们移植代码。 但我们认为这个问题可以解决。

如果代码已经使用文件相对路径调用 openat，那么只要编译该代码就能用。

如果代码使用的是 open 并且迁移到 openat 风格的前期开销太高，WASI 可以提供一个增量解决方案。 使用 libpreopen，可以为应用程序创建一个合理需要访问的文件路径列表。 然后就可以使用 open 了，不过只能使用列表中的路径。

下一步呢？

我们认为 wasi-core 是一个良好的开端。 它保持了 WebAssembly 的可移植性与安全性，为生态系统提供了坚实的基础。

不过，在 wasi-core 完全标准化之后，我们还需要解决一些问题。这些问题包括：

• 异步 I/O
• 文件监视
• 文件锁定

这只是开始，所以如果你有解决这些问题的想法，就请加入我们吧！

关于英文原文作者 Lin Clark

Lin 在 Mozilla 的高级开发部门工作，专注于 Rust 与 WebAssembly。

• https://twitter.com/linclark
• @linclark

Lin Clark 的更多文章……

Ktor 是 JetBrains 官方出品的互联应用框架。 使用该框架非常易于开发异步的服务器与客户端，并且能够充分利用 Kotlin 以及协程的优势。

Ktor 中文站是官方英文站的中文翻译（目前还在翻译中，欢迎组团一起）。 初学者可以从快速入门入手来学习与了解 Ktor，这一章大多数内容均已翻译。

上周六，有幸在 JetBrains 开发者日上分享了《Ktor——Kotlin 多平台异步 Web 框架实践》 ，这两天也把讲稿及相关 demo 整理了下。

讲稿可在这里下载：

链接： https://share.weiyun.com/5UqjtTc
密码： eauq37

我猜你还想看 Benny 分享的讲稿，传送门在这里：2018 JetBrains 开发者大会见闻

这份讲稿比当天用的那份要新一些（其中的截图也能看出是 11 月 20 日的），补充了当场提到但没有在讲稿中列出的 Ktor 适用场景： 多平台项目，同时开发客户端与服务端，比如同时开发 WebSocket 或者直接套接字通讯的客户端与服务器。

CallID 与 Call Logging MDC 的 demo 在这里：

https://github.com/hltj/ktor-callid-demo

接口聚合服务 demo 在这里：

https://github.com/hltj/kaggregator-demo

最后出场的这个是原打算在分享中讲的开源缩略图服务 Kthumbor，终于完成了第一个可用版。服务框架使用 Ktor，100% Kotlin 开发，见下图：

另外，在 Kthumbor 项目中采用了测试驱动开发的方式（其中测试框架使用的是 KotlinTest），先写测试用例后写实现。 目前只实现了最简单的生成指定宽高内的缩略图的功能，后续还会实现放大、剪裁等功能，最终会实现一个生产级可用的缩略图服务。

Kthumbor 的源代码在这里：

https://github.com/hltj/kthumbor

欢迎反馈与交流。 需要说明的一点是，我并不想做纯雷锋，该项目采用 AGPL-3.0 协议发布，因此可以用于商业目的，但是任何修改都需要以同样协议（AGPL-3.0）开源出来。

关于分享中讲到的点以及 Kthumbor 项目，有机会再展开来看。

更新

Java 9 已经正式发布半年多了。这期间不仅 Java 9 发布了更新，就连 Java 10 也已正式发布。上一篇中提到的工具也都有更新。其中 IDEA 新版改进了不少 Java 9 支持，Eclipse 新版内置了 Java 9 支持（不再需要 Beta 版插件，但可能需要重装，不能直接从旧版升级）。最值得一提的是 lombok 1.16.20 发布。

2018-12-28 注：Java 9 与 Java 10 都是短期版本，目前的长期支持（LTS）版是 Java 11。 而 Java 10 与 Java 11 自身的改动都不多，可以说 Java 11 相对于上一个 LTS 版（Java 8）的新特性很多都是 Java 9 引入的。因此本文仍有参考价值。 Oracle 已经不提供 JDK 9 下载，一些示例可以直接使用 Java 11 来演练，或者用历史版本的 OpenJDK（不推荐）。

Lombok 兼容性改善

期待已久的 lombok 1.16.20 终于在 2018-01-09 正式发布。这一版解决了上一篇中提到的大多数兼容问题。具体如下：

1. 可以与 Gradle 4.1 及以上版本配合使用。 这点很重要，因为 Gradle 4.2 及以上版本才能支持 Java 9.0.1/9.0.4。
2. 改进 IDE 支持。 将上一篇中提到的 Lombok 示例 中的 Lombok 版本升级到 1.16.20 后，在新版 IDEA 中无论创建普通项目、Maven 项目还是 Gradle 项目，都能正常编辑与运行；在新版 Eclipse 中，Maven、Gradle 项目正常，普通项目还是有问题；在新版 NetBeans 开发版中普通项目、Maven 项目均正常，Gradle 项目在 JDK 9 环境正常，JDK 9.0.1/9.0.4 环境有问题。

结合一篇的内容，汇总 Lombok 1.16.18 到 1.16.20 兼容情况变化如下表所示：

表中箭头（⇨）之前表示 Lombok 1.16.18 对工具的兼容情况，箭头之后表示 Lombok 1.16.20 的兼容情况。

Java 9 更新与版本号模式

Java 9 的安全更新版 9.0.1、9.0.4 分别于 2017-10-17、2018-01-16 发布。可以看出这里的 Java 版本号与以往 1.8.0_162 这种版本号差异很明显。Java 9 的版本号模式（version schema）为：

$MAJOR.$MINOR.$SECURITY

即“主版本号.次版本号.安全级别”，这样很容易看出 9.0.1 与 9.0.4 都是安全修复版本，应该升级。

Java 9 还增加了用于获取版本号的 API，以前取 Java 版本号主要通过系统属性来取，现在可以直接调用 API 了。java.lang.Runtime 新添了一个静态方法 version()，其返回值类型为 Runtime.Version，通过它可以很方便地获取不同格式的版本号。例如：

jshell> Runtime.version()
$1 ==> 9.0.4+11

jshell> Runtime.version().version()
$2 ==> [9, 0, 4]

jshell> Runtime.version().major()
$3 ==> 9

jshell> Runtime.version().security()
$4 ==> 4

jshell> Runtime.version().build()
$5 ==> Optional[11]

值得补充的是，Java 10 再次修改版本号模式为：

$FEATURE.$INTERIM.$UPDATE.$EMERG

即“特性版本号.中间版本号.更新版本号.紧急修复版本号”。 同时 Runtime.Version 的相应方法 major()、minor()、security() 也被弃用，建议分别使用新增的 feature()、interim()、update() 方法取代，另外新增 patch() 方法用于取紧急修复版本号。例如：

jshell> Runtime.version()
$1 ==> 10+46

jshell> Runtime.version().feature()
$2 ==> 10

jshell> Runtime.version().build()
$3 ==> Optional[46]

当然 Java 10 与 Java 9 的前三位版本号的含义并不完全相同。特别是自 Java 10 起将严格按照 6 个月的节奏发版，即今年三月份发布 Java 10、九月份发布 Java 11、明年三月份发布 Java 12……以此类推。

关于 Java 9 与 Java 10 版本号模式的更多内容请参见 JEP 223: New Version-String Scheme 以及 JEP 322: Time-Based Release Versioning。

非重大改动

接下来介绍以下内容：

• 下划线成为保留字
• try-with-resource 改进
• InputStream 改进
• 接口的私有默认方法
• 集合的工厂方法
• Optional 改进
• Stream 改进
• 进程 API 改进

如果已经了解过就不需要再往下看了。

下划线成为保留字

单独一个下划线（_）作为标识符在 Java 8 中就已经弃用，但是仍然可以通过编译。例如下述代码：

public class Demo0 {
    public static void main(String[] args) {
        int _ = 1;
        System.out.println(_);
    }
}

在 Java 8 环境中编译会出现以下警告：

$ javac Demo0.java 
Demo0.java:3: warning: '_' used as an identifier
        int _ = 1;
            ^
  (use of '_' as an identifier might not be supported in releases after Java SE 8)
Demo0.java:4: warning: '_' used as an identifier
        System.out.println(_);
                           ^
  (use of '_' as an identifier might not be supported in releases after Java SE 8)
2 warnings
$ java Demo0
1

而在 Java 9 环境中则不能通过编译：

$ javac Demo0.java
Demo0.java:3: error: as of release 9, '_' is a keyword, and may not be used as an identifier
        int _ = 1;
            ^
Demo0.java:4: error: as of release 9, '_' is a keyword, and may not be used as an identifier
        System.out.println(_);
                           ^
2 errors

在 JShell 中使用也会出现同样的报错：

jshell> String _ = "foo";
|  Error:
|  as of release 9, '_' is a keyword, and may not be used as an identifier
|  String _ = "foo";
|         ^

这是因为 _ 已经成为保留字，在未来的 Java 版本中有可能用作占位符，类似 Scala 的模式匹配语法或者 Kotlin 的解构语法中的占位符。

try-with-resource 改进

Java 7 引入了 try-with-resource 语法，对于支持自动清理的资源（实现了 AutoCloseable 接口的类型），将引用创建的语句放在 try 与左花括号之间圆括号中，就可以执行自动清理。例如

try (BufferedReader br = new BufferedReader(new FileReader(path))) {
    return br.readLine();
}

对于既有引用，在 Java 7/8 中需要引入临时变量，例如：

BufferedReader br = new BufferedReader(new FileReader(path));
try (BufferedReader br1 = br) {
    return br1.readLine();
}

而在 Java 9 中，使用既有 final（或相当于 final）的可自动清理资源引用时无需引入临时变量。上述代码可以简化为：

BufferedReader br = new BufferedReader(new FileReader(path));
try (br) {
    return br.readLine();
}

InputStream 改进

Java 9 的 InputStream 新添了一个 transferTo() 方法，可以从输入流读取并写到输出流。例如，在 JShell 中用一行代码实现终端输入回显（按 Ctrl-C 结束）：

jshell> System.in.transferTo(System.out)
Hello
Hello
0123456789
0123456789

$1 ==>

有了这个函数，实现类似 IOUtils.toString() 的逻辑就很方便了：

jshell> String inputToString(InputStream is) throws IOException {
   ...>    ByteArrayOutputStream os = new ByteArrayOutputStream();
   ...>    is.transferTo(os);
   ...>    return os.toString();
   ...> }
|  created method inputToString(InputStream)

jshell> inputToString(new ByteArrayInputStream("Hello".getBytes()))
$2 ==> "Hello"

接口的私有默认方法

Java 8 引入了接口的默认方法，可以为接口提供默认实现。例如我们有一个接口 Person 以及很多实现该接口的类，当我们为 Person 接口新增 greeting()、farewell() 两个方法时，可以为其提供默认实现，而无需每个实现 Person 接口的类都实现一遍：

public interface Person {
    // 其他接口 ……

    String getName();

    default void greeting() {
        System.out.println(getName() + ": Hello!");
    }

    default void farewell() {
        System.out.println(getName() + ": Goodbye!");
    }
}

Java 9 的接口支持私有默认方法，可以让多个默认方法复用代码：

public interface Person {
    // 其他接口 ……

    String getName();

    default void greeting() {
        say("Hello!");
    }

    default void farewell() {
        say("Goodbye!");
    }

    private void say(String words) {
        System.out.println(getName() + ": " + words);
    }
}

假如这里的私有默认方法 say() 并没有调用实例方法 getName()，那么还可以使用静态私有方法：

public interface Person {
    // 其他接口 ……

    default void greeting() {
        say("Hello!");
    }

    default void farewell() {
        say("Goodbye!");
    }

    private static void say(String words) {
        System.out.println(words);
    }
}

集合的工厂方法

在 Java 9 之前，创建带有初始字面值的只读 List、Set 与 Map 的代码语法风格各异，甚至有些繁琐麻烦。例如：

// import static java.util.Collections.unmodifiableSet;
// import static java.util.Collections.unmodifiableMap;
// import static java.util.stream.Collectors.collectingAndThen;
// import static java.util.stream.Collectors.toSet
// import static java.util.stream.Collectors.toMap
// import static java.util.AbstractMap.SimpleEntry;

final List<String> list = Arrays.asList("foo", "bar", "baz");

final Set<Integer> numbers = unmodifiableSet(new HashSet<Integer>() {
    {
        add(1); add(2); add(3);
    }
});

// 或者
final Set<Integer> numbers1 =
    unmodifiableSet(new HashSet<Integer>(Arrays.asList(1, 2, 3)));


// 或者（Java 8）
final Set<Integer> numbers2 =
Stream.of(1, 2, 3)
    .collect(collectingAndThen(toSet(), Collections::unmodifiableSet));

final Map<Integer, String> map =
    unmodifiableMap(new HashMap<Integer, String>() {
        {
            put(1, "foo");
            put(2, "bar");
            put(3, "baz");
        }
    });

// 或者（Java 8）
final Map<Integer, String> map1 =
    unmodifiableMap(Stream.of(
        new SimpleEntry<>(1, "foo"),
        new SimpleEntry<>(2, "bar"),
        new SimpleEntry<>(3, "baz"))
            .collect(toMap((e) -> e.getKey(), (e) -> e.getValue()))
    );

而在 Java 9 中可以使用更简洁、更直观、更统一的方式：

// import static java.util.Map.entry

final List<String> list = List.of("foo", "bar", "baz");

final Set<Integer> numbers = Set.of(1, 2, 3);

final Map<Integer, String> map = Map.of(1, "foo", 2, "bar", 3, "barz");

// 或者
final Map<Integer, String> map1 = Map.ofEntries(
    entry(1, "foo"),
    entry(2, "bar"),
    entry(3, "baz")
);

Optional 改进

新增 or 方法

Optional 类新增 or() 方法，它与 orElseGet() 类似，只是其参数 lambda 的返回值以及自身的返回值都是 Optional，可以用于从一系列可选值中选取第一个有值的。例如：

jshell> import static java.util.Optional.*;

jshell> empty().or(() -> empty()).or(() -> empty())
$2 ==> Optional.empty

jshell> empty().or(() -> empty()).or(() -> of("Hello")).or(() -> empty())
$3 ==> Optional[Hello]

jshell> empty().or(() -> of("Wolrd")).or(() -> of("Hello")).or(() -> empty())
$4 ==> Optional[Wolrd]

注：只有 Optional 类新添了这个方法，而 OptionalInt 等可选类并未添加。

新增 ifPresentOrElse 方法

在 Java 8 中可选类都实现了 ifPresent，可以很容易实现有值时输出其内容：

jshell> OptionalDouble.of(Math.PI).ifPresent(System.out::println)
3.141592653589793

但如果要同时实现无值时输出默认值，它就无能为力了。这时 Java 9 的 ifPresentOrElse 就派上用场了：

jshell> OptionalDouble.of(Math.PI).ifPresentOrElse(System.out::println, () -> System.out.println("No Value"))
3.141592653589793

jshell> OptionalDouble.empty().ifPresentOrElse(System.out::println, () -> System.out.println("No Value"))
No Value

新增 stream 方法

在 Java 8 中如果想对 OptionalInt 等基本类型可选值做流式集合处理会非常麻烦：

jshell> OptionalLong optlong = OptionalLong.of(1L)
optlong ==> OptionalLong[1]

jshell> (optlong.isPresent()? LongStream.of(optlong.getAsLong()): LongStream.empty()).map(x ->x + 1).boxed().collect(Collectors.toList())
$2 ==> [2]

Java 9 添加了 stream() 方法可使其简化很多：

jshell> optlong.stream().map(x ->x + 1).boxed().collect(Collectors.toList())
$3 ==> [2]

Stream 类改进

新增 ofNullable 工厂方法

在 Java 9 中如需对可空对象进行流式集合处理，可以借助 Optional 来实现：

jshell> Optional.ofNullable("hello").stream().count()
$1 ==> 1

jshell> Optional.ofNullable(null).stream().count()
$2 ==> 0

另外，Java 9 也为 Stream 类添加了 ofNullable() 方法，上述代码还可以简化为：

jshell> Stream.ofNullable("hello").count()
$3 ==> 1

jshell> Stream.ofNullable(null).count()
$4 ==> 0

注：只有 Stream 类新添了这个方法，而 IntStream 等并未添加。

新增 takeWhile 与 dropWhile 方法

分别用于“取元素直到指定值出现”、“直到指定值出现开始取元素”，例如：

jshell> import static java.util.stream.Collectors.toList;

jshell> IntStream.of(9, 6, 3, 0, 2, 4, 6).takeWhile(n -> n != 0).boxed().collect(toList())
$2 ==> [9, 6, 3]

jshell> IntStream.of(9, 6, 3, 0, 2, 4, 6).dropWhile(n -> n != 0).boxed().collect(toList())
$3 ==> [0, 2, 4, 6]

iterate 方法新增重载

使用 Java 8 的 iterate 以及上述 takeWhile 实现输出 10 以内的偶数如下：

jshell> IntStream.iterate(0, i -> i + 2).takeWhile(i -> i <= 10).forEach(System.out::println)
0
2
4
6
8
10

不过 Java 9 还为 iterate 新添了支持判断迭代条件的重载形式，因此上述代码可改为：

jshell> IntStream.iterate(0, i -> i <= 10, i -> i + 2).forEach(System.out::println)
0
2
4
6
8
10

进程 API 改进

Java 9 新增了 ProcessHandle 接口，可以很方便地获得进程的 pid 与进程信息。ProcessHandle 还提供了两个静态方法，分别用于获取当前进程与指定 pid 的 ProcessHandle 实例。例如：

jshell> ProcessHandle.current().pid()
$1 ==> 27137

jshell> ProcessHandle.current().parent()
$2 ==> Optional[27112]

jshell> ProcessHandle.of(27112).get().children().count()
$3 ==> 1

jshell> ProcessHandle.current().info().command()
$4 ==> Optional[/usr/local/jdk-9.0.4/bin/java]

jshell> ProcessHandle.current().info().totalCpuDuration()
$5 ==> Optional[PT0.81S]

关于这些新特性的更多细节请参见官方文档。

本系列未完待续。

2018-12-28 注：Java 9 是一个短期版本，目前的长期支持（LTS）版是 Java 11。 而 Java 10 与 Java 11 自身的改动都不多，可以说 Java 11 相对于上一个 LTS 版（Java 8）的新特性很多都是 Java 9 引入的。因此本文仍有参考价值。 上述下载链接已失效，一些示例可以直接使用 Java 11 来演练，或者用历史版本的 OpenJDK（不推荐）。

Java 9 没有像 Java 5/Java 8 那样引入新的编程范式而给语言本身带来革命性的改进，不过 Java 9 的改动还是很大的，尤其是引入模块化对 JDK 与运行时的改动都很大。 现在网上能找到很多介绍 Java 9 新特性的文章，这里不再赘述，只简要列举如下：

1. 模块化（Jigsaw 项目）
2. G1 成为默认垃圾收集器
3. JDK 自带 REPL 即 JShell
4. 支持 HTTP/2 与 WebSocket 的新版 HTTP 客户端
5. 多版本 Jar 包
6. 语言、JDK、运行时与工具的其他优化与改动

如何切换到 Java 9，Oracle 官网上也有详细的迁移文档。

而如何获得最直观的感受，就不妨跟我一起来亲身体验下了。

Hello World

千万不要觉得用体验一门新语言的方式来体验一个新版本是小儿科或者小题大做。 因为 Hello World 能运行至少意味着基本环境没问题，如果不能就说明我们发现了问题。

Hello JShell

JShell 是 JDK 9 自带的交互式编程命令行，即 REPL（Read-Eval-Print Loop 的简写，直译为 “读取-求值-输出”循环），非常适合快速实验一些代码片段。 它遵循通用的命令行操作，如 Tab 自动补全、Ctrl-D 退出、Ctrl-R 反向搜索、Ctrl-S 正向搜索等等。 运行 jshell --help 可以查看其命令行选项说明，直接运行 jshell 进入交互式模式后，可以通过 /help 查看交互式模式帮助。 更详细的用法说明可参见其官方文档。

交互式 Hello World

运行 jshell 进入交互式模式：

$ jshell
|  欢迎使用 JShell -- 版本 9
|  要大致了解该版本, 请键入: /help intro

jshell> 

jshell> 是 JShell 的命令提示符，可在其后直接键入代码。在 JShell 中直接输入可运行的代码就可以，无需定义额外的类与 main 函数，还可以省略单行语句的分号。 因此运行 Hello World 只需键入 System.out.println("Hello, World!") 即可，并且在输入过程中还可以通过 Tab 键补全：

jshell> System.out.println("Hello, World!")
Hello, World!

大功告成。当然，如果只是想在 JShell 中查看一个表达式的求值结果，并不需要调用 System.out.println() 这么麻烦，而只需直接键入表达式然后回车即可：

jshell> "Hello, World!"
$2 ==> "Hello, World!"

jshell> Math.PI * 1.5 * 1.5
$3 ==> 7.0685834705770345

这实际上是 JShell 的“反馈”，如果希望反馈中包含表达式的类型，可以在启动时加命令行选项 -v 或者通过交互模式的命令 /set feedback verbose 切换到详细反馈模式：

jshell> /set feedback verbose
|  反馈模式: verbose

jshell> "Hello, World!"
$4 ==> "Hello, World!"
|  已创建暂存变量 $4 : String

jshell> double areaOfCircle(double radius) {
   ...>     return Math.PI * radius * radius;
   ...> }
|  已创建 方法 areaOfCircle(double)

jshell> areaOfCircle(1.5)
$6 ==> 7.0685834705770345
|  已创建暂存变量 $6 : double

更多交互式模式的用法可以查阅文档或自行发掘，现在通过快捷键 Ctrl-D 或者交互式命令 /exit 退出 JShell，来看下非交互式 JShell 版 Hello World。

Hello JShell 脚本

除了交互式运行，JShell 还可以用作脚本执行。 现在我们将输出 Hello World 的语句写入一个文件：

$ echo 'System.out.println("Hello, World!")' > hello.jsh

然后用 JShell 运行之：

$ jshell hello.jsh
Hello, World!
|  欢迎使用 JShell -- 版本 9
|  要大致了解该版本, 请键入: /help intro

jshell> 

在执行完 hello.jsh 中的语句后进入了交互式模式，这并不是预期的结果，我们希望它执行完就退出而不是进入交互式模式。 当然，这只需在文件末尾追加 /exit 命令即可：

$ echo '/exit' >> hello.jsh
$ jshell hello.jsh
Hello, World!

又大功告成了！（奇怪，我为什么要说又 :P）。比较遗憾的是 JShell 目前还不支持 shbang，不能将 .jsh 文件直接作为可执行脚本来用。

构建运行 Hello World

对于 Hello World 这样简单的代码片段，确实只用 JShell 演练就可以了。只是这并不能验证构建运行也一切正常，因此还要继续来看使用 JDK 9 构建运行 Hello World 程序的情形。

直接编译运行

直接编译运行与 JDK 8 及以前版本没有任何区别：

$ cat > Hello.java << END
> public class Hello {
>     public static void main(String[] args) {
>         System.out.println("Hello, World!");
>     }
> }
> END
$ javac Hello.java
$ java Hello
Hello, World!

而我们在实际项目中通常并不能如此简单地编译运行，而需使用 Maven 或者 Gradle 来构建项目。

注：本文中测过的 Maven 版本为 3.3.9、3.5.0；Gradle 版本为 3.5-RC-2 到 4.0.2。

Hello Maven

现在我们将 Hello.java 的开头加上包声明 package me.hltj.java9demo.hello;，并将其放到 src/main/java/me/hltj/java9demo/hello 目录下，然后创建 pom.xml 如下：

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

    <modelVersion>4.0.0</modelVersion>

    <groupId>me.hltj</groupId>
    <artifactId>java9demo-hello</artifactId>
    <version>1.0-SNAPSHOT</version>

</project>

这样就创建了一个简单的 maven 项目。 如果使用 JDK 8，此时就可以通过 mvn package 生成 jar 包，并通过以下命令来运行：

$ java -cp target/java9demo-hello-1.0-SNAPSHOT.jar me.hltj.java9demo.hello.Hello

但是使用 JDK 9 编译会报错：

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project java9demo-hello: Compilation failure: Compilation failure:
[ERROR] Source option 1.5 is no longer supported. Use 1.6 or later.
[ERROR] Target option 1.5 is no longer supported. Use 1.6 or later.
[ERROR] -> [Help 1]

这是因为 Maven 默认的源代码和目标版本都是 1.5，而 JDK 9 支持的最低版本是 1.6，因此必须在 pom.xml 中显式指定这两个版本号：

    <properties>
        <maven.compiler.source>1.9</maven.compiler.source>
        <maven.compiler.target>1.9</maven.compiler.target>
    </properties>

之后就可以像使用 JDK 8 一样正常构建和运行了。

Hello Gradle

首先为项目创建 gradle wrapper 并基于 maven 项目初始化：

$ gradle wrapper --gradle-version=4.0.2 --distribution-type=bin
$ ./gradlew init

然后将 build.gradle 简化为：

apply plugin: 'java'

group = 'me.hltj'
version = '1.0-SNAPSHOT'

无需指定源代码与目标版本就可以正常构建运行：

$ ./gradlew build
BUILD SUCCESSFUL in 1s
$ java -cp build/libs/java9demo-hello-1.0-SNAPSHOT.jar me.hltj.java9demo.hello.Hello
Hello, World!

除了构建工具外，在实际项目开发中也离不开 IDE，接下来我们就看下在不同 IDE 中使用 Java 9 构建与运行的情况。

Hello IDEA

最新稳定版的 IDEA（2017.2.4）已支持 Java 9。 在其中使用 Java 9 构建与运行 Hello World 与 Java 8 无异，只需选用 JDK 9 即可：

如果尚未添加点击上图所示的对话框右上方的“New”按钮来添加。 之后可以照常构建与运行 Hello World，无论创建项目时选 Java 项目、Maven 项目还是 Gradle 项目。

Hello Eclipse

最新稳定版的 Eclipse Oxygen（4.7.0）并没有内置 Java 9 支持，需要安装一个 Beta 版的 Java 9 支持插件才行：

之后就可以添加 JDK 9 了：

添加完成后就可以通过 JDK 9 照常构建与运行 Hello World，无论创建项目时选 Java 项目、Maven 项目还是 Gradle 项目。

Hello NetBeans

最新稳定版的 NetBeans（8.2）并不支持 Java 9，也没有用于 Java 9 支持的插件。 想要支持 Java 9 只能用每日构建版，可在这里下载： http://bits.netbeans.org/download/trunk/nightly/latest/。

在安装时选 JDK 9。之后可以照常构建与运行 Hello World，无论创建项目时选 Java 项目还是 Maven 项目。

注：NetBeans 虽然有 Gradle 插件，但是在每日构建版中安装之后也基本无法使用。

Hello World 小结

以任何方式通过 JRE 9 运行 Hello World 都如预期般顺利。使用 Gradle 或者 IDEA 通过 JDK 9 构建 Hello World 示例项目也一如既往地顺利。 而对于 Maven 需要注意显式指定源代码与目标版本，对于 Eclipse 需要安装插件，对于 NetBeans 目前只能用每日构建版。

注：示例代码已放到 Github 上： https://github.com/hltj/java9demo/tree/master/hello。

Hello World 总体上看还比较顺利，接下来我们看下更具挑战的 Lombok 支持情况。

Java 9 中使用 Lombok

代码冗长是 Java 语言广为病诟的缺点之一。而其中很多场景都可以使用 Lombok 来简化，这在实际项目中广泛应用。 因此验证 JDK 9 以及使用 JDK 9 的构建工具与 IDE 对 Lombok 的支持情况尤为重要，会关系到很多既有项目能否迁移到 Java 9。

这里以一段简单代码为例，验证 Maven、Gradle、IDEA、Eclipse、NetBeans 在使用 JDK 9 时对 Lombok 的支持情况。代码如下：

package me.hltj.java9demo.lombok;

import lombok.*;
import lombok.extern.slf4j.Slf4j;

@Value
@ToString
class Language {
    @NonNull
    private String name;
    private int version;
}

@Slf4j
public class LombokDemo {
    public static void main(String[] args) {
        val version = Integer.parseInt(System.getProperty("java.version"));

        val java = new Language("Java", version);

        log.info("Hello Lombok in {}.", java);
    }
}

使用 Maven 构建

我们只需创建相应代码目录结构，然后在 pom.xml 中配置以下依赖即可在 Java 8 下通过编译：

    <dependencies>
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <version>1.16.18</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>ch.qos.logback</groupId>
            <artifactId>logback-classic</artifactId>
            <version>1.2.3</version>
        </dependency>
    </dependencies>

当然为了便于运行还引入了 assembly 插件，另外设置源代码与目标级别为 1.8，完整的 pom.xml 参见 https://github.com/hltj/java9demo/blob/7a704a1b4a60cab74e454ab8d2d7edda30af430f/lombok/pom.xml。 此时使用 JDK 8、JDK 9 都能正常编译，但只有在 Java 9 环境中才能正常运行，因为 Java 8 的版本号如“1.8.0_144”不能解析为整数，运行时会抛异常。

但是当我们把 pom.xml 中的源代码与目标的版本号升级为 1.9 时，却编译失败了：

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project java9demo-lombok: Compilation failure: Compilation failure: 
[ERROR] /home/hltj/java9demo/lombok/src/main/java/me/hltj/java9demo/lombok/LombokDemo.java:[6,1] 程序包 javax.annotation 不可见
[ERROR]   (程序包 javax.annotation 已在模块 java.xml.ws.annotation 中声明, 但该模块不在模块图中)

这是因为 Lombok 默认在每个生成的方法上添加了注解 @javax.annotation.Generated("lombok")，而在 Java 9 引入模块化系统后不再默认提供这一注解。 解决方案有：

1. 在 lombok.config 中添加以下配置来禁用这一行为：

   lombok.addJavaxGeneratedAnnotation = false
   

2. 给 javac 增加参数 --add-modules=java.xml.ws.annotation。
3. 采用安卓项目针对此问题的解决方案，添加一个提供该注解的依赖： org.glassfish:javax.annotation:10.0-b28。

例如采用第三种方案，只需在 pom.xml 中追加以下配置：

        <dependency>
            <groupId>org.glassfish</groupId>
            <artifactId>javax.annotation</artifactId>
            <version>10.0-b28</version>
            <scope>provided</scope>
        </dependency>

之后就可以使用 Java 9 顺利构建运行了：

$ java -jar target/java9demo-lombok-1.0-SNAPSHOT-jar-with-dependencies.jar
17:24:57.723 [main] INFO me.hltj.java9demo.lombok.LombokDemo - Hello Lombok in Language(name=Java, version=9).

使用 Gradle 构建

初始化 Gradle 之后将 build.gradle 改成这样即可使用 JDK 8 编译：

apply plugin: 'java'
apply plugin: 'application'

group = 'me.hltj'
version = '1.0-SNAPSHOT'

mainClassName = 'me.hltj.java9demo.lombok.LombokDemo'

repositories {
    mavenCentral()
}

dependencies {
    compileOnly "org.projectlombok:lombok:1.16.18"
    compile "ch.qos.logback:logback-classic:1.2.3"
}

但是使用 JDK 9 编译会遇到与 Maven 构建时相同的问题，这里采用第二种方案，在 build.gradle 中追加以下配置即可：

compileJava {
    options.compilerArgs += ['--add-modules', 'java.xml.ws.annotation']
}

注意：目前 Gradle 4.1 到 4.2-RC-2 版无法使用 JDK 9 编译这个项目，这也是本文只验证了 Gradle 3.5-RC-2 到 4.0.2 版的原因。

在 IDEA 中使用

如果 IDEA 中已安装 Lombok 插件，并且在项目中开启了注解处理，就能够正常解析 Lombok 注解。但是很遗憾的是，无法直接在 IDEA 中使用 JDK 9 构建：

在 IDEA 中要使用 JDK 9 编译这个项目，需采用将构建与运行委托给 Gradle 的方式：

这样能够通过 Gradle 来构建，而运行还需要再做几步。首先点击第 15/16 行左侧的运行按钮：

在弹出菜单中选择“Run”，此时“Run”窗口中默认显示的是各个 Gradle 任务的执行情况，需要点击侧栏的按钮将其切换到文本模式才能看到输出：

在 Eclipse 中使用

如果已运行过 lombok.jar 为 Eclipse 添加支持，并且在项目配置中启用了注解处理，那么 Eclipse 能够正常解析代码中的大多数 Lombok 注解，只有 @Value、@ToString 这两行有问题。

在 Eclipse 中要使用 JDK 9 编译这个项目，需要通过 Maven 方式来构建运行，而且还要去除代码中 @Value 与 @ToString 注解并修改相关联代码：

在 NetBeans 中使用

在 Netbeans 每日构建版中即便开启注解处理，仍然只能识别出注解本身，而不能进行相应语义处理，可认为无法解析 Lombok 注解。

在 Netbeans 中要使用 JDK 9 编译这个项目，需要通过 Maven 方式来构建运行：

使用 Lombok 小结

在 Java 9 环境中使用 Lombok 需要确保编译期有能够提供 javax.annotation 的模块可用或者在配置中禁用 javax 注解。 Maven/Gradle 项目使用 JDK 9 编译都不成问题，使用 Gradle 4.1 到 4.2-RC-2 版除外。 三款 IDE 中只有 IDEA 能够良好解析 Lombok 注解，Maven 项目只有每日构建版的 NetBeans 能够顺利构建运行，Gradle 项目只有 IDEA 能够构建运行。

注：示例代码已放到 Github 上： https://github.com/hltj/java9demo/tree/master/lombok。

如此看来工具支持还有待提升，那么对于既有项目来说，切换到 Java 9 有收益吗？ 当然有！Java 9 不仅提供了新功能，也有很多优化的地方。让我们看一个简单、直观的示例。

性能提升的示例

以之前在由“千万字母表问题”看多范式编程语言中的 Java 代码为例，使用 Java 9 运行的效率相对 Java 8 有显著提升。 以下是我分别在不同环境中运行三次取中位数的结果：

当然这只是说明 Java 9 的 JVM/JRE 在一些场景中相对于 Java 8 有显著的性能提升。而新版 JDK、新的 API、新的工具同样能够带来很多收益，这些会在本系列后续文章中展开。

结论

JShell 很适合简短代码的演练。 JDK 9 的 IDE 支持还有待改善，短期内并不适合使用 JDK 9 进行项目开发。 但是无论 JRE 9 的性能提升还是 Java 9 引入的新功能都很值得进一步关注。

本系列后续文章会更多关注 Java 9 的新特性，同时如果发现 IDE 支持有改善也会一并提及，以便大家能够尽早用上。