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