甲骨文公司 正在向OpenJDK提供GraalVM社区版的Java代码，以使GraalVM技术的开发与 Java 的开发更紧密地结合起来。

GraalVM 原生编译能降低启动延迟。使用 Loom 和 GraavVM，可以免费的方式快速启动 JVM 了。

Graal 是一个非常非常雄心勃勃的项目， Oracle 多年来一直在资助它。它的边缘仍然很粗糙，但它有望使新的编程语言能够在高性能 JVM 上运行，并编译为本机代码。一次写入，随处运行，以本机速度运行。

此次，Oracle 贡献 GraalVM 即时 (JIT) 编译器和 Native Image 的最有用的部分

但是，Oracle 目前不打算贡献支持 Python 、 Ruby 、R 和 Java script 等其他语言的多语言技术。仍然是完全开源的（一如既往），只是不会成为 OpenJDK 的一部分。

JVM 和 Graal 不再是镇上唯一的游戏了。Webassembly 在客户端、边缘、后端等各个领域都在增长。WASM 满足了与 Graal 相同的大部分需求，并且由于它嵌入在每个主要浏览器中，因此也满足了一些需求。

此举对 Graal 有利，将帮助它竞争，但至少在我看来，Graal 是否能够长期竞争仍然存在一个大问题。是的，我知道 Graal 也可以执行 WASM 生成的二进制文件，所以它在这个环境中可能有空间，但它会胜过原生 WASM 虚拟机吗？WASM 是否会成为事实上的 二进制 格式，用于运送过去使用 JVM 字节码的东西？

TeaVM 是 Java 字节码的提前编译器，它能支持在浏览器中运行的 JavaScript 和 WebAssembly。它的近亲是众所周知的 GWT。主要区别在于 TeaVM 不需要源代码，只需要编译的类文件. 而且，源代码不需要是Java，所以TeaVM可以成功编译 Kotlin 和 Scala 。

如果 Chrome 和 Safari 提供通过 <script> 标签访问的 GraalVM，有多少人会关心 WASM？
使用graal，你可以

• – 运行在OpenJDK上解释interpreted 的wasm，类似于在nashorn中解释interpreted 的javascript，或者现在的graalvm，你只需要在你的依赖中加入几个graal sdk的罐子即可。
• – 运行已编译的wasm，你需要在GraalVM上运行这个。相比上一个，这应该能提供大约50倍的速度。

前端是指你能否将WASM代码作为输入送入到Graal。后端是指你能不能让Graal产生的WASM代码作为输出。