Java
FFM（Foreign Function & Memory API）将为许多后续功能奠定基础，这些功能不仅限于AOT（Ahead-of-Time Compilation）/Native Image、GUI/
Javafx等。此外，Value Object的实现也依赖于这一特性。可以说，有了FFM之后，开发者甚至可以自己动手创建Value Object。而虚拟线程（Virtual Threads）则主要对网络IO密集型场景产生深远影响，例如Web框架（如
Spring）以及JDBC相关的应用。总体来看，虚拟线程对于
Java Web框架的影响更为显著，比如在
Spring中的表现；但从对整个JDK生态的影响程度来说，显然FFM更具深远意义，特别是与GraalVM相关联的部分。虚拟线程更侧重于性能优化，它能够显著减少现有
Java系统占用的资源，尤其在IO密集型应用场景中，内存消耗会大幅降低。这种优化使得
Java在处理大规模并发任务时更加高效。而FFM则更偏向于功能增强，它让一些原本
Java难以实现或者无法完成的任务变得简单可行。通过FFM，
Java用户真正迈入了原生时代。过去使用JNI（
Java Native Interface）时，开发者不仅要编写
Java代码，还需要编写C语言代码来对接底层功能。这违背了许多选择
Java用户的初衷——他们本来就是为了避免接触复杂的C语言开发而来。然而，使用JNI不仅增加了工作量，还因为与C语言对接不成熟而引发诸多问题。这些问题长期得不到解决，导致JNI自1.0版本以来几乎没有变化，其功能已远远落后于时代需求，因此备受批评。特别值得一提的是，FFM团队的负责人分别来自意大利和
印度。这两个国家的工作效率在国际上常被质疑，甚至有人认为他们的散漫程度可能超过法国人。尽管如此，FFM的推出确实带来了革命性的改变。通过FFM，
Java可以直接替代部分C语言的功能，用纯
Java代码以类似C的方式操作底层资源。例如，可以定义一块连续的内存区域（Memory Segment），对其进行字节级别的读写操作，并将其交给垃圾回收器（GC）管理。此外，还可以调整Memory Segment的大小，尽管这一操作存在潜在风险，需要通过特定选项显式授权才能执行。相比之下，JNI目前没有类似的限制，但未来可能会跟进这一安全机制。除了核心功能外，FFM还附带提供了jextract工具。该工具可以从C语言头文件生成对应的
Java代码，从而让用户无需手动编写或编译C代码即可直接调用现有的C库。这种方式极大简化了跨语言开发流程，避免了传统JNI模式下繁琐的编译步骤，使得开发者只需专注于
Java代码的编写即可完成与C库的交互。这不仅提高了开发效率，还减少了因手动编写C代码而引入错误的可能性。FFM的出现标志着
Java在功能扩展性和性能优化方面迈出了重要一步，为未来的创新奠定了坚实基础。
