为什么 java.lang.ref.Reference<T> 不实现 Supplier<T>？答案

【问题标题】：Why doesn't java.lang.ref.Reference<T> implement Supplier<T>?为什么 java.lang.ref.Reference<T> 不实现 Supplier<T>？
【发布时间】：2015-10-28 20:28:53
【问题描述】：

我正在查看 java.lang.ref.Reference 类（以及它的子类），我想知道为什么它没有实现 Java 8 的 Supplier<T> 接口。

看来这应该是不费吹灰之力。供应商的get() 方法满足Reference。我犹豫要自己实现 SoftReference<T> 的扩展同时实现 Supplier<T> 的唯一原因是因为我知道 References 是垃圾收集器的特殊情况。

制作这样的课程有什么问题可以预见

public class SoftReferenceSupplier<T> extends SoftReference<T> implements Supplier<T>
{
    public SoftReferenceSupplier(T referent)
    {
        super(referent);
    }

    public SoftReferenceSupplier<T referent, ReferenceQueue<? super T> queue)
    {
        super(referent,queue);
    }
}

我不想以某种方式破坏 SoftReferences 的目的，因为一些垃圾收集警告会干扰供应商的处理方式。

顺便说一句，我知道SoftReferences 将在完整的垃圾回收后返回null。我的程序中需要SoftReferences，我想让它实现这个函数接口以增加灵活性。

【问题讨论】：

因为这会破坏向后兼容性。 Reference 是 java 2，Supplier 是 java 8。如果 Reference 实现了 Supplier，java 2 将需要 java 8。也因为它没有意义（Reference 是一个包装器，而不是值的提供者）。
为什么会增加灵活性？
您不能将ref::get 传递给任何需要供应商的方法吗？
@sturcotte06 为什么会破坏向后兼容性？ Java2 用户不会受到影响，因为更改只会出现在 Java 8（或 9）中。 String 没有在 Java 2 中实现 CharSequence，现在它实现了，作为一个反例。
所有从 java Reference<T> 的客户端都会被破坏。此外，String 是最终类，Sun（或 Oracle）可以用它做任何他们想做的事情，只要更改只是附加的。

标签： java reference garbage-collection functional-interface

【解决方案1】：

Reference 比 Supplier 早很多。据我所知，将Reference<T> 更改为实现Supplier<T> 不会破坏任何现有代码，但在我看来这没有多大意义。当所有新的功能接口都被引入到语言中时，本来可以遍历每个现有的类，让每个类都实现每个碰巧有匹配方法的新功能接口，但我看不到这个。

在很多情况下，一个类实际上实现了一个函数式接口是没有意义的，因为如果你需要将一个对象看作一个函数式接口的实例，你可以只使用方法引用。

Reference<Object> reference = new WeakReference<>(someObject);
Supplier<Object> supplier = reference::get;

这个解决方案不取决于这两种方法恰好都被称为get，所以在我看来，最好让Reference实现Supplier。

【讨论】：

【解决方案2】：

我做了一些谷歌搜索，但没有找到任何与为什么 Java 的 Reference class 没有实现 Supplier interface 相关的内容。但是Supplier 的Javadoc 留下了一些线索。我认为答案在于Supplier 是如何被引入 Java 的——即作为用于 Lambda 表达式的函数式编程接口。两个get() 方法的含义只是逻辑上不同的东西。 Reference类实例的get()方法返回所指对象； Supplier 实例的 get() 方法返回 lambda 表达式的结果。很难想象两者之间的语义重叠，除非我正在创建一个涉及 JVM 软引用、弱引用和/或幻像引用的 lambda 表达式。

【讨论】：