Spring Native是未来吗？

当出现一个新技术时，我们不是无脑的学习，而需要思考这门技术为什么出现？为什么是这个时候出现？以及它的未来在哪里？想清楚了之后，再考虑是否学习和使用。经过社会的毒打之后，只剩下这点不多的灵魂，慰藉青春的在天之灵。

所以，spring native支持将项目打包成可执行文件，这意味着什么？

这个问题等价于：可执行文件的优缺点在哪里？我们为什么要使用？

可执行文件的优缺点

优点

在我看来有以下几个好处：

1. 包更小：都是二进制，而不是还需要二次解析的class文件；
2. 启动速度快：不像JVM启动会有个预热过程；
3. 消耗资源更少：这里主要是指内存，因为没有JVM的开销了。

当然，可执行文件对应的缺点也是存在的。

缺点

目前将Java编译成静态文件的东西也是个VM，这就是 GraalVM，已经有国人写了相关书籍，大家可以看看。

在 GraalVM的官方里，也列举了一些限制。不过，在我看来，这些问题是可以解决的。
而比较大的问题有2个。

跨平台

这其实和Java最初宣传的口号（一次编译，到处运行）相违背。
Java应用最大的特点就是跨平台，能在易用性和性能之间取得良好的平衡，这是Java能够这么流行的关键原因。然而，编译成二进制就需要看平台了。

动态代码生成

动态代码生成技术在Java里用的很常见，很多框架都使用了，最常见的是SQL执行框架，比如 Apache Calcite，Spark SQL, 每个SQL是不确定的，SQL的执行计划也不确定，就需要使用代码生成物理执行计划。

我们知道，代码需要经过 预处理、编译、优化、汇编、链接等步骤才能变成可执行文件，在JVM里的class文件很容易实现这个功能。但是只有一个可执行文件时遇到代码生成怎么办？

我们以Go语言为例，Go语言到目前为止是做不到的。仔细想想可知，编译Go能够那么快，因为有Go的编译环境，在每台运行的机器上都装上Go的编译环境也是可以实现的，不过真有人这样做吗？这不就和每台机器都安装JDK一样的道理嘛。

所以，我觉得这个功能不会是这样实现的，这等价于一个可执行文件需要自带编译器，这包的大小也不会小吧。

为什么需要spring native？

经过上面的缺点分析，我们可以知道：Spring native是绝不可能用在所有场景的。至少Spring的定位是做业务系统，而不是中间件，所以那些底层的代理、反射技术，业务系统一般不会用。所以，写底层中间件的同志们可能要失望了，这个native不是那么好用的。

而关于它的优点才是我们要关注的，这几个小、快、少的特点在哪些场景亟需？------ 容器化、微服务。

相信使用Spring Cloud做微服务的同志深有体会，微服务的理念是什么？“微”，我就一个简单的接口，20MB的jar包就来了，对于开发者和部署来说实在不友好。

现在是云时代，设计应用的时候考虑什么？能在云上运行，这就是云原生的概念。而k8s和docker是云时代事实上的王者。
Java这个老年人要适应新时代，势必要做出一些改变。

可能Java也早就感觉到其下降的市场份额&强大的竞争者，比如Python和Go，特别是Go。这一举措显然是在和Go竞争，也是未来的一个趋势吧。

听起来不错，用起来就不爽了

想要跃跃欲试的同学已经按捺不住了，不过，事实很骨感，先不说Spring Native才刚发出 Beta版不久。就算稳定了，也不会倒退支持JDK8，因为下面是其支持的环境：

• Java 11, Java 17 and Kotlin 1.5+
• docker 或者 GraalVM
• springboot版本目前只支持2.6.2

一个是JDK至少要11，Spingboot版本也非常高。对于咱们大多数还在使用JDK8的公司来说，这个升级代价有点大。不过至少又多了一丝希望和助力。

所以，Spring Native是未来吗？

当然是呀，因为未来还很遥远，我们走着瞧！