java 后续class_Java 9引入的AOT编译方式的意义何在，对后续Java程序的影响在哪里？...

12 release了，差不多可以回答这个问题了

先说一个常识，jdk目前的那个jaotc，也就是jdk.aot.jmod，其实是graalvm的一部分，就是graal的aot

然后是这样，意义就是字面上的意义，可以将java代码或者class文件也就是字节码直接编译成机器码，好处就是节省了jit的时间，不需要预热就可以直接执行了，如果只考虑单个平台，比如mac/win/linux的话，那native image的大小会变小，hello world只要20多m，甚至可以更小，听说可以做到6m，而且业界还有声音说，还不够小，还要再小一点

但是坏处也很明显，那就是破坏了跨平台的特性，以steam上发布软件为例，一般我们会这么做，针对win做一个runtime，针对mac做一个runtime，针对linux做一个runtime，所谓runtime，就是把平台相关的部分单独做成一个文件夹，然后再把跨平台共通的部分，单独做成一个或者几个jar，然后捆绑一起打包上传，这样做的好处就是，把跨平台和不跨平台的部分分离，跨平台的部分就可以共用代码了，这也是封装最原始的目的

但是如果我们做了aot之后，那连同原来跨平台的部分也会变得不跨平台，于是你得对所有平台全部做aot处理，当然这也有好处，就是如果不同平台分开下载链接的话，最终下载的size还是比较小的，但是对于steam这种统一下载平台的平台来说，aot就不太方便了

总之这是一个工具，怎么用就看你自己决定了

最后说一个头疼的问题，你要在不同平台上做aot，你需要下载对应平台的编译工具，比如mac的xcode，win的visual studio，这几个都几个G大小，贼78大，非常烦，估计用这些工具的程序员都在用这些工具看电影，相比之下，openjdk才100多m，真的是非常贴心了，同样问题在flutter那边也存在

所以短期内我们暂不会采用aot，jit其实足够用了，也就是说真正的用处没有想象的大，native code还是不碰比较好，因为编译环境都会变得很大，动不动都是要几个g的下载，算了