vivo|时代的变迁!OpenJDK 17 计划弃用并删除安全管理器功能

【vivo|时代的变迁!OpenJDK 17 计划弃用并删除安全管理器功能】vivo|时代的变迁!OpenJDK 17 计划弃用并删除安全管理器功能

出品|开源中国
作者|罗奇奇
为了推动 Java 向前发展 , OpenJDK 17 打算弃用其安全管理器(Security Manager)功能 , 以便与旧的小应用 API (JEP 398)一起删除 。
安全管理器功能可追溯到 Java 1.0 , 在我们用按键手机或者诺基亚在 Web 浏览器上下载 Java 游戏小应用(Applet)的时代 , 安全管理器通过在沙箱中运行小游戏 , 从而拒绝它访问文件系统或网络等资源 , 保护我们的设备的安全性和数据的隐私性 。 安全管理器会批准所有涉及可信任代码资源访问的操作 , 但拒绝不可信代码的资源访问 。

但随着时代变迁和 Java 库的激增 , 安全管理器变得力不从心 , 随着搭载 Android 智能手机的普及 , Java 平台也不再支持小应用这种格式 , 安全管理器使用的环境变得更少了 。 多年来 , 它一直不是保护客户端 Java 代码的主要手段 , 也很少用于保护服务器端代码 。
安全管理器三宗罪:

  • 脆弱的权限模型
安全管理器必须授予应用程序执行操作所需的所有权限 , 无法进行部分安全性访问控制 。 例如 , 用户担心非法的访问数据 , 因此要求安全管理器授予应用只从特定目录读取文件的权限 , 但只有文件读取权限是不够的 , 因为应用程序肯定会使用 Java 类库中除了读取文件之外的其他操作(例如写入文件) , 而这些其他操作将被安全管理器拒绝 。
  • 困难的编程模型
安全管理器通过检查一次操作的所有代码权限 , 以决定来批准安全敏感操作 , 使得编写与安全管理器一起运行的库变得困难 , 因为库开发人员不会记录其库代码所需的一切权限 。
  • 性能差
安全管理器的核心是一个复杂的访问控制算法 , 通常会带来不可接受的性能损失 。 因此 , 默认情况下 , 对于在命令行上运行的 JVM , 安全管理器始终处于禁用状态 。
基于上述种种原因 , 这个见证移动设备发展史的功能即将从 Java 中移除 , 按键手机和它的 Java 小应用也随岁月一去不返 。