爲什麼java.lang.ref.Reference <T>實現供應商<T>？

我在看類java.lang.ref.Reference（和它的子類），我想知道爲什麼它不實現Java 8的Supplier<T>接口。爲什麼java.lang.ref.Reference <T>實現供應商<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的目的有多麼供應商的interferring預見任何問題的處理。

順便說一句，我知道SoftReferences將返回一個完整的垃圾回收null。我在我的程序中需要SoftReferences，我希望它能夠實現這個功能接口以增加靈活性。

來源

2015-10-28 HesNotTheStig

因爲這會破壞向後兼容性。參考是java 2，供應商是java 8.如果參考實現了供應商，那麼java 2將需要java 8.同樣因爲它沒有意義（引用是一個包裝器，而不是值的提供者）。 – sturcotte06

爲什麼它會增加靈活性？ –

難道你不能只通過'ref :: get'到任何需要供應商的方法嗎？ – VGR

我做了一些Google搜索，但沒有發現任何與Java爲什麼Reference class沒有實現Supplier interface相關的任何內容。但是Javadoc的Supplier留下了一些線索。我認爲答案在於如何將Supplier引入到Java中，即作爲用於Lambda表達式的函數式編程接口。兩種方法的含義僅僅意味着邏輯上不同的東西。 Reference類的實例的get()方法返回指示對象; Supplier實例的get()方法返回lambda表達式的結果。很難想象這兩者之間存在語義重疊，除非我創建了一個涉及JVM軟，弱和/或幻影引用的lambda表達式。

來源

2015-10-30 06:14:45 entpnerd

Reference比Supplier要舊很多。據我所知，更改Reference<T>來實現Supplier<T>不會破壞任何現有的代碼，但在我看來，它不會有很大的意義。當所有新的功能接口都被引入到語言中時，就有可能通過每一個已經存在的類，並使每一個新的功能接口都實現碰巧有一個匹配方法的每個新的功能接口，但是我看不到這個。

在很多情況下，根本不需要實際實現一個功能接口的類，因爲如果您需要將一個對象視爲一個功能接口的實例，則可以使用方法引用。

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

該解決方案確實不依賴於這樣的事實，這兩種方法恰巧都被稱爲get，所以在我看來，最好是使Reference實施Supplier。

來源

2015-11-09 14:15:17

爲什麼java.lang.ref.Reference <T>實現供應商<T>？

回答

相關問題