为什么使用原始“int”的“Comparator”在这段代码中起作用？如果自动装箱，什么时候发生？

Question

我将此代码编写为另一个问题的解决方案：

record Person( String name , int age ) { }
List < Person > persons =
        List.of(
                new Person( "Alice" , 52 ) ,
                new Person( "Bob" , 23 ) ,
                new Person( "Carol" , 39 )
        );

List < Person > sorted =
        persons
                .stream()
                .sorted( Comparator.comparing( Person :: age ) )
                .toList();

此代码在 Java 17。

persons.toString() = [Person[name=Alice,age=52],Person[name=Bob,age=23],Person[name=Carol,age=39]]

sorted.toString() = [人物[姓名=鲍勃，年龄=23]，人物[姓名=卡罗尔，年龄=39]，人物[姓名=爱丽丝，年龄=52]]

经过进一步思考，我对这段代码的工作原理感到惊讶。我将 记录 上的访问器方法（“getter”）的方法引用传递给 Comparator.comparing 调用。

Comparator.comparing( Person :: age )

…但是age成员字段和该方法的返回类型都是int基元，而不是对象。

Answer 1

我将留给读者一个练习，即 Person::age 的解析过程识别潜在适用的方法 intage()作为精确方法引用表达式。确定目标方法后，来自 JLS 15.13.2：

如果以下两个条件都成立，则方法引用表达式与函数类型一致：

• 函数类型标识与引用相对应的单个编译时声明。
• 以下情况之一是正确的：[...]
  • 函数类型的结果是 R，将捕获转换（第 5.1.10 节）应用于所选编译时声明的调用类型（第 15.12.2.6 节）的返回类型的结果是 R'（其中 R 是可用于推断 R' 的目标类型，并且 R 和 R' 都不是 void，并且 R' 在赋值上下文中与 R 兼容。

这里的函数类型是Function。 T 显然是 Person，而 comparing 的签名需要一些 U extends Comparable。

int 类型与赋值上下文中的Integer 兼容，随后也与 Comparable 兼容（ JLS 5.2):

赋值上下文允许使用以下之一：[...]

• 先进行装箱转换，然后再进行扩大参考转换