AbstractPreferences是類Preferences的子類，此類允許應用程式存儲和獲取用戶和系統首選項以及配置數據，從JDK1.4版開始出現。此類提供了 Preferences 類的骨幹實現，從而大大簡化了實現此類的任務。實現者必須重寫九個抽象服務提供者接口 (SPI) 方法，所有的具體方法都精確指定它們如何在這些 SPI 方法上實現。
基本介紹
- 中文名：AbstractPreferences
- 作用：JDK1.4提供了Preferences類，
- 接口 (SPI)：實現者必須重寫九個抽
- SPI 方法：SPI 方法按異常行為可分
作用,九個抽象服務提供程式接口 (SPI),SPI 方法,實現注意事項,
作用
JDK1.4提供了Preferences類，可以把Preferences理解為對Java的Properties的補充和擴展，使Java在保存系統的配置、運行狀態等信息時，更加具有彈性和靈活性。Preferences類在不同的平台中有不同的實現方式。比如在Windows平台中，Preferences是將數據保存在註冊表中的。
public abstract class AbstractPreferencesextends Preferences此類提供了 Preferences 類的骨幹實現，從而大大簡化了實現此類的任務。
此類僅供 Preferences 實現者使用。Preferences 設施的普通用戶無需參考此文檔。Preferences 文檔已經足夠了。
九個抽象服務提供程式接口 (SPI)
實現者必須重寫九個抽象服務提供程式接口 (SPI) 方法：getSpi(String)、putSpi(String,String)、removeSpi(String)、childSpi(String)、removeNodeSpi()、keysSpi()、childrenNamesSpi()、syncSpi() 和 flushSpi()。所有的具體方法都精確指定它們如何在這些 SPI 方法上實現。如果出於某種考慮（如性能）對默認實現不滿意，則實現者可能決定重寫一個或多個具體方法。
SPI 方法
SPI 方法按異常行為可分為三個組。getSpi 方法應該永遠不拋出異常，但是對性能絲毫不會產生影響，因為 get(String,String) 會攔截此方法所拋出的任何異常，並對調用方返回指定的默認值。removeNodeSpi、keysSpi、childrenNamesSpi、syncSpi 和 flushSpi 方法被指定拋出 BackingStoreException；如果實現無法執行操作，則需要拋出此經過檢查的異常。該異常向外傳播，導致相應的 API 方法失敗。
其餘的 SPI 方法 putSpi(String,String)、removeSpi(String) 和 childSpi(String) 具有更加複雜的異常行為。未指定它們拋出 BackingStoreException，因為即使內部存儲不可用，它們通常也遵守其協定。之所以這樣是因為它們不返回任何信息，並且在進行對 {Preferences#flush()} 或 {Preferences#sync()} 的後續調用之前，不要求其結果是持久的。一般而言，這些 SPI 方法不應?>拋出異常。在某些實現中，可能存在這些調用甚至無法對後續處理的請求操作進行排隊的情形。即使在這些情形下，最好的做法也是忽略該調用並返回，而不是拋出異常。但是，在這些情形下，所有 flush() 和 sync 的後續調用應該返回 false，因為返回 true 意味著以前的所有操作都已成功地成為持久性操作。
有一種情況下 putSpi、removeSpi 和 childSpi 應該 拋出異常：如果調用方在基礎作業系統上不具備執行請求操作的足夠許可權。例如，如果非特權用戶嘗試修改系統首選項，則在大多數系統上都會發生這種情況。（這要求特權隨實現而變化。在有些實現中，需要修改檔案系統中某些目錄內容的特權；而在另外一些實現中，則需要修改註冊表中某些鍵的內容。）在上述任何情形下，通常讓程式繼續執行並不合乎需要，就好像這些操作在以後會成為持久操作一樣。雖然在這些情形下不要求實現拋出異常，但還是鼓勵這樣做。SecurityException 就是合適的選擇。
大多數 SPI 方法都要求實現在首選項節點上讀取或寫入信息。實現者需要注意一種情況，即另一個 VM 當前可能已經從內部存儲刪除了此節點。如果該節點已經刪除了，則實現有責任重新創建它。
實現注意事項
：在 Sun 的默認 Preferences 實現中，用戶的身份是從基礎作業系統繼承的，在虛擬機的生命周期中不能更改。在伺服器端的 Preferences 實現中，用戶身份可以隨請求而更改，並通過使用靜態 ThreadLocal 實例隱式傳遞給 Preferences 方法。大力 提倡這種實現的設計者在訪問首選項時確定用戶（例如，使用 get(String,String) 或 put(String,String) 方法），而不是將用戶與每個 Preferences 實例永久關聯。後一種行為與通常的 Preferences 用法有衝突，將帶來很大的混亂。
