甲骨文公司正在向OpenJDK提供GraalVM社区版的Java代码,以使GraalVM技术的开发与Java的开发更紧密地结合起来。
GraalVM 原生编译能降低启动延迟。使用 Loom 和 GraavVM,能以免费方式快速启动 JVM了。
Graal 是一个非常非常雄心勃勃的项目,Oracle 多年来一直在资助它。它的边缘仍然很粗糙,但它有望使新的编程语言能够在高性能 JVM 上运行,并编译为本机代码。一次写入,随处运行,以本机速度运行。
此次,Oracle 贡献 GraalVM 即时 (JIT) 编译器和 Native Image 的最有用的部分
但是,Oracle 目前不打算贡献支持 Python、Ruby、R 和 JavaScript 等其他语言的多语言技术。不过这些未贡献技术仍然是完全开源的(一如既往),只是不会成为 OpenJDK 的一部分。
JVM 和 Graal 不再是镇上唯一的游戏了。Webassembly 在客户端、边缘、后端等各个领域都在增长。WASM 满足了与 Graal 相同的大部分需求,并且由于它嵌入在每个主要浏览器中,因此也满足了一些需求。
此举有助于Graal 与WASM竞争,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代码作为输出。