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 年后却可能并不理想。
更多详情可查看提案。