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

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

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

安全管理器三宗罪：

• 脆弱的權限模型

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

• 困難的編程模型

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

• 性能差

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

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