为了推动Java向前发展，OpenJDK17打算弃用其安全管理器（SecurityManager）功能，并与旧的小型应用程序API（JEP398）一起移除。SecurityManager功能可以追溯到Java1.0，回到我们在带有键盘电话或诺基亚的网络浏览器上下载Java游戏小程序(applet)的日子，SecurityManager通过在沙盒系统或网络中运行小程序来拒绝其访问文件和其他资源，以保护我们设备的安全和数据的隐私。安全管理器批准所有涉及可信代码资源访问的操作，但拒绝不可信代码的资源访问。但是，随着时代的变迁，Java库的泛滥，安全管理器已经力不从心了。随着Android智能手机的普及，Java平台不再支持小应用的格式，安全管理器使用的环境也变少了。多年来，它并不是保护客户端Java代码的主要手段，也很少用于保护服务器端代码。安全管理者的三大罪过：脆弱的权限模型安全管理者必须授予应用程序执行操作所需的所有权限，不能进行部分安全访问控制。例如，用户担心数据被非法访问，于是要求安全管理器授予应用程序只能从特定目录读取文件的权限，但只有文件读取权限是不够的，因为应用程序肯定会使用Java类库中除了读取文件以外的其他操作（比如写入文件）都会被安全管理器拒绝。困难的编程模型安全管理器通过检查操作的所有代码权限来批准安全敏感操作，这使得编写与安全管理器一起工作的库变得困难，因为库开发人员没有记录他们的库代码需要所有权限的内容。性能不佳安全管理器的核心是复杂的访问控制算法，通常会带来不可接受的性能损失。因此，对于在命令行上运行的JVM，安全管理器在默认情况下始终处于禁用状态。由于上述所有原因，这个见证了移动设备历史的功能即将从Java中删除，按钮电话及其Java小程序将永远消失。
