時代的變遷！OpenJDK 17 計劃棄用並刪除安全管理器功能

出品|開源中國

作者|羅奇奇

為了推動 Java 向前發展，OpenJDK 17

打算棄用

其安全管理器（Security Manager）功能，以便與舊的小應用 API （

JEP 398

）一起刪除。

安全管理器功能可追溯到 Java 1。0，在我們用按鍵手機或者諾基亞在 Web 瀏覽器上下載 Java 遊戲小應用（

Applet

）的時代，安全管理器透過在沙箱中執行小遊戲，從而拒絕它訪問檔案系統或網路等資源，保護我們的裝置的安全性和資料的隱私性。安全管理器

會批准所有涉及可信任程式碼資源訪問的操作，但拒絕不可信程式碼的資源訪問。

但隨著時代變遷和 Java 庫的激增，安全管理器變得力不從心，隨著搭載 Android 智慧手機的普及，Java 平臺也不再支援小應用這種格式，安全管理器使用的環境變得更少了。多年來，它一直不是保護客戶端 Java 程式碼的主要手段，也很少用於保護伺服器端程式碼。

安全管理器三宗罪：

脆弱的許可權模型

安全管理器必須授予應用程式執行操作所需的所有許可權，無法進行部分安全性訪問控制。例如，使用者擔心非法的訪問資料，因此要求安全管理器授予應用只從特定目錄讀取檔案的許可權，但只有檔案讀取許可權是不夠的，因為應用程式肯定會使用 Java 類庫中除了讀取檔案之外的其他操作（例如寫入檔案），而這些其他操作將被安全管理器拒絕。

困難的程式設計模型

安全管理器透過檢查一次操作的所有程式碼許可權，以決定來批准安全敏感操作，使得編寫與安全管理器一起執行的庫變得困難，因為庫開發人員不會記錄其庫程式碼所需的一切許可權。

效能差

安全管理器的核心是一個複雜的訪問控制演算法，通常會帶來不可接受的效能損失。因此，預設情況下，對於在命令列上執行的 JVM，安全管理器始終處於禁用狀態。

基於上述種種原因，這個見證移動裝置發展史的功能即將從 Java 中移除，按鍵手機和它的 Java 小應用也隨歲月一去不返。