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

提案内容指出，类文件生成、解析和检测在 Java 生态系统中无处不在；许多工具和库需要能够处理类文件，并且框架通常执行动态字节码检测、转换和生成。JDK 应该为读取、写入和转换 Java 类文件提供准确、完整、最新、高性能的 API。

该 API 的目标是在最初取代 ASM 作为 JDK 的一个运行时依赖项，而不会出现不可接受的性能损失。且作为一个扩展目标，最好还能取代编译器和 JDK 工具所使用的内部"classreader"库。最终，大量的应用程序和框架应该能够有效地使用这个库来替代 ASM、cglib 或其他字节码库。设计目标和原则包括让所有类文件实体（例如方法和字段）由不可变对象表示以及用户驱动的 navigation 等。​​​​​​​

其动机在于：

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

更多详情可查看提案。