為了推動 Java 向前發(fā)展，OpenJDK 17 打算棄用其安全管理器(Security Manager)功能，以便與舊的小應(yīng)用 API ( JEP 398 )一起刪除。

安全管理器功能可追溯到 Java 1.0，在我們用按鍵手機或者諾基亞在 Web 瀏覽器上下載 Java 游戲小應(yīng)用（Applet）的時代，安全管理器通過在沙箱中運行小游戲，從而拒絕它訪問文件系統(tǒng)或網(wǎng)絡(luò)等資源，保護我們的設(shè)備的安全性和數(shù)據(jù)的隱私性。安全管理器會批準(zhǔn)所有涉及可信任代碼資源訪問的操作，但拒絕不可信代碼的資源訪問。

但隨著時代變遷和 Java 庫的激增，安全管理器變得力不從心，隨著搭載 Android 智能手機的普及，Java 平臺也不再支持小應(yīng)用這種格式，安全管理器使用的環(huán)境變得更少了。多年來，它一直不是保護客戶端 Java 代碼的主要手段，也很少用于保護服務(wù)器端代碼。

安全管理器三宗罪：

• 脆弱的權(quán)限模型

安全管理器必須授予應(yīng)用程序執(zhí)行操作所需的所有權(quán)限，無法進行部分安全性訪問控制。例如，用戶擔(dān)心非法的訪問數(shù)據(jù)，因此要求安全管理器授予應(yīng)用只從特定目錄讀取文件的權(quán)限，但只有文件讀取權(quán)限是不夠的，因為應(yīng)用程序肯定會使用 Java 類庫中除了讀取文件之外的其他操作（例如寫入文件），而這些其他操作將被安全管理器拒絕。

• 困難的編程模型

安全管理器通過檢查一次操作的所有代碼權(quán)限，以決定來批準(zhǔn)安全敏感操作，使得編寫與安全管理器一起運行的庫變得困難，因為庫開發(fā)人員不會記錄其庫代碼所需的一切權(quán)限。

• 性能差

安全管理器的核心是一個復(fù)雜的訪問控制算法，通常會帶來不可接受的性能損失。因此，默認(rèn)情況下，對于在命令行上運行的 JVM，安全管理器始終處于禁用狀態(tài)。

基于上述種種原因，這個見證移動設(shè)備發(fā)展史的功能即將從 Java 中移除，按鍵手機和它的 Java 小應(yīng)用也隨歲月一去不返。