没有虚拟机的 Java

• 某些 Java 语言的特性，使得 Graal VM 编译本地镜像的过程变得极为艰难。譬如常见的反射，除非使用 安全管理器 去专门进行认证许可，否则反射机制具有在运行期动态调用几乎所有 API 接口的能力，且具体会调用哪些接口，在程序不会真正运行起来的编译期是无法获知的。反射显然是 Java 不能放弃不能妥协的重要特性，为此，只能由程序的开发者明确地告知 Graal VM 有哪些代码可能被反射调用（通过 JSON 配置文件的形式），Graal VM 才能在编译本地程序时将它们囊括进来。

  [
      {
          name: "com.github.fenixsoft.SomeClass",
          allDeclaredConstructors: true,
          allPublicMethods: true
      },
      {
          name: "com.github.fenixsoft.AnotherClass",
          fileds: [{name: "foo"}, {name: "bar"}],
          methods: [{
              name: "<init>",
              parameterTypes: ["char[]"]
          }]
      },
      // something else ……
  ]
  

  这是一种可操作性极其低下却又无可奈何的解决方案，即使开发者接受不厌其烦地列举出自己代码中所用到的反射 API，但他们又如何能保证程序所引用的其他类库的反射行为都已全部被获知，其中没有任何遗漏？与此类似的还有另外一些语言特性，如动态代理等。另外，一切非代码性质的资源，如最典型的配置文件等，也都必须明确加入配置中才能被 Graal VM 编译打包。这导致了如果没有专门的工具去协助，使用 Graal VM 编译 Java 的遗留系统即使理论可行，实际操作也将是极度的繁琐。
• 大多数运行期对字节码的生成和修改操作，在 Graal VM 看来都是无法接受的，因为 Substrate VM 里面不再包含即时编译器和字节码执行引擎，所以一切可能被运行的字节码，都必须经过 AOT 编译成为原生代码。请不要觉得运行期直接生成字节码会很罕见，误以为导致的影响应该不算很大。事实上，多数实际用于生产的 Java 系统都或直接或间接、或多或少引用了 ASM、CGLIB、Javassist 这类字节码库。举个例子，CGLIB 是通过运行时产生字节码（生成代理类的子类）来做动态代理的，长期以来这都是 Java 世界里进行类增强的主流形式，因为面向接口的增强可以使用 JDK 自带的动态代理，但对类的增强则并没有多少选择的余地。CGLIB 也是 Spring 用来做类增强的选择，但 Graal VM 明确表示是不可能支持 CGLIB 的，因此，这点就必须由用户（面向接口编程）、框架（Spring 这些 DI 框架放弃 CGLIB 增强）和 Graal VM（起码得支持 JDK 的动态代理，留条活路可走）来共同解决。自 Spring Framework 5.2 起，@Configuration 注解中加入了一个新的 proxyBeanMethods 参数，设置为 false 则可避免 Spring 对与非接口类型的 Bean 进行代理。同样地，对应在 Spring Boot 2.2 中，@SpringBootApplication 注解也增加了 proxyBeanMethods 参数，通常采用 Graal VM 去构建的 Spring Boot 本地应用都需要设置该参数。
• 一切 HotSpot 虚拟机本身的内部接口，譬如 JVMTI、JVMCI 等，在都将不复存在了——在本地镜像中，连 HotSpot 本身都被消灭了，这些接口自然成了无根之木。这对使用者一侧的最大影响是再也无法进行 Java 语言层次的远程调试了，最多只能进行汇编层次的调试。在生产系统中一般也没有人这样做，开发环境就没必要采用 Graal VM 编译，这点的实际影响并不算大。
• Graal VM 放弃了一部分可以妥协的语言和平台层面的特性，譬如 Finalizer、安全管理器、InvokeDynamic 指令和 MethodHandles，等等，在 Graal VM 中都被声明为不支持的，这些妥协的内容大多倒并非全然无法解决，主要是基于工作量性价比的原因。能够被放弃的语言特性，说明确实是影响范围非常小的，所以这个对使用者来说一般是可以接受的。
• ……

3rd party libraries

Graal VM native support needs to be sustainable and maintainable, that's why we do not want to maintain fragile pathches for the whole JVM ecosystem.

The ecosystem of libraries needs to support it natively.

—— Sébastien Deleuze，DEVOXX 2019