何时/为什么我想使用Groovy的@CompileStatic？

Question

我已经读过这个：http://docs.groovy-lang.org/latest/html/gapi/groovy/transform/CompileStatic.html，而且这个：Should I use Groovy's @CompileStatic if I'm also using Java 7，并且理解肯定会有性能改进，但是它是什么？我并不完全明白@CompileStatic做了什么。

是否有某些类添加@CompileStatic是明智的？我不想要它在哪里？

Answer 1

引用我对Should I use Groovy's @CompileStatic if I'm also using Java 7的回答：

  

虽然比正常的Groovy更快，但它只能编译Groovy的一个子集，并且行为有点不同。特别是所有动态功能都不再可用。

所有MOP都将被绕过。建设者一般不会工作，有些人会对编译器进行扩展以允许他们通过。此外，在编译时使用静态类型选择方法，而Groovy通常使用运行时可用的方法和运行时类型。这可能导致调用不同的方法。

当然@CompileStatic也提供了一些安全性，因为编译器的任务是在运行时验证程序。但由于静态信息注定不完整，因此永远不会有100％的安全性。

那么它在哪里是明智的......好吧......例如POGO，因为它们通常不包含所有那么多代码。当然还有通过复制和粘贴从Java移植到Groovy的类。

我想要它在哪里？好吧，目前可能在Android上，因为代码大小有影响，静态编译代码更紧凑。否则我个人可以完全不使用@CompileStatic。这更像是品味问题。在某些情况下，紧密循环会有性能提升，但这需要您通过首先分析应用程序进行识别

Answer 2

当AOT编译常规程序时（例如，使用 GraalVM @CompileStatic工具），发现native-image can be useful。 native-image MethodHandle支持仅限于MethodHandle对象是编译时间常数的情况。通过使用像这样的编译器配置：

import groovy.transform.CompileStatic
withConfig(configuration) {
    ast(CompileStatic)
}

可以消除生成的字节码中的动态MethodHandle实例，并让GraalVM 提前编译成功。