查看原文
其他

OpenJDK 提案将提供 Java 类文件 API

程序猿DD 2022-07-01

出品 | OSC开源社区(ID:oschina2013)

Java 社区正在酝酿一项 Classfile API 提案,旨在提供一个用于解析、生成和转换 Java 类文件的 API;最初将作为 JDK 中 ASM 的内部替代品,之后再作为公共 API 开放。根据计划,ASM 最终将被完全从 JDK 中删除。

提案内容指出,类文件生成、解析和检测在 Java 生态系统中无处不在;许多工具和库需要能够处理类文件,并且框架通常会执行 on-the-fly bytecode instrumentation、transformation 和 generation。JDK 应该为读取、写入和转换 Java 类文件提供准确、完整、最新、高性能的 API。

该 API 最初的目标是在不造成不可接受的性能损失的情况下,取代 ASM 作为 JDK 的一个运行时依赖项。且作为一个扩展目标,最好还能进一步取代编译器和 JDK 工具所使用的内部 "classreader" 库。最终,期望能够有大量的应用程序和框架可以使用这个库来有效地替代 ASM、cglib 或其他字节码库。设计目标和原则包括让所有 Class file entities(例如方法和字段)由 immutable objects 表示以及用户驱动的 navigation 等。

图片

其萌发的动机在于:

  • JDK 整合。JDK 本身在处理类文件方面很重要。JDK 使用 ASM 存在固有的延迟,JDK 开发人员需要一个与 JVMS 保持同步的字节码库。
  • 框架和运行 JDK 之间的版本偏差。处理类文件的应用程序和框架通常捆绑一个类文件库,例如 ASM、cglib 等。但是由于新的类文件功能可以出现在任何 JDK 版本中,且在 Java 9 之后 JDK 的发布速度大大加快,应用程序和框架更频繁地遇到比它们捆绑的库更新的类文件,从而导致运行时错误(或者更糟糕的是,框架试图 “从未来” 解析类文件格式)。开发人员需要一个与运行 JDK 保持同步的类文件库。
  • JVM 进化。与 Java 早期相比,JVM 和类文件格式现在的发展速度要快得多。虽然有些演变很简单,但有些演变更复杂,例如 Project Valhalla 带来了新的字节码、字段描述符和验证规则。在某些时候,改进现有库以支持这些新功能可能会代价很大或很复杂。
  • 语言改进。自从编写 ASM 以来,该语言已经有了很大的改进,这意味着在 2002 年可能是最好的 API 习惯用法在 20 年后却可能并不理想。

更多详情可查看提案:https://bugs.openjdk.org/browse/JDK-8280389

我们创建了一个高质量的技术交流群,与优秀的人在一起,自己也会优秀起来,赶紧点击加群,享受一起成长的快乐。另外,如果你最近想跳槽的话,年前我花了2周时间收集了一波大厂面经,节后准备跳槽的可以点击这里领取

推荐阅读

··································

你好,我是程序猿DD,10年开发老司机、阿里云MVP、腾讯云TVP、出过书创过业、国企4年互联网6年。从普通开发到架构师、再到合伙人。一路过来,给我最深的感受就是一定要不断学习并关注前沿。只要你能坚持下来,多思考、少抱怨、勤动手,就很容易实现弯道超车!所以,不要问我现在干什么是否来得及。如果你看好一个事情,一定是坚持了才能看到希望,而不是看到希望才去坚持。相信我,只要坚持下来,你一定比现在更好!如果你还没什么方向,可以先关注我,这里会经常分享一些前沿资讯,帮你积累弯道超车的资本。

点击领取2022最新10000T学习资料

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存