Java 老矣? 非也！
「今日推荐」
来源 | CSDN说好不能打脸
2020年TIOBE’s对于各种编程语言排名情况的总结是：“Python is TIOBE’s Programming Language of 2020”。这无疑是对写了多年Java程序的小伙伴是相当有震撼力的一句话，曾几何时我们调侃delphi、调侃Ruby的样子和近些年自己被调侃的样子极为相似。
Python的快速发展、Java的被赶超、Ruby的夕阳余晖有其语言自身的因素，也有各大厂商推波助澜的因素，还有其生态圈发展情况等等因素，但笔者认为那些都是表面现象。而最大影响因素是由社会对信息化应用、数字化应用的需求所决定的。一门高级语言是不是有活力，主要是看它能不能低成本解决各行业对各类软件方案进行快速复制的要求。这些成本可以包括人力资源、单位时效、需求匹配度、行业所需的运行效能各个方面。
而作为程序员，特别是生活在当前物质环境下的程序员，我们对于一门语言的选择往往取决于建立在此基础上的下一维度的考量，例如就业机会如何、学习成本如何、薪资水平如何、持续性如何、内卷风险如何甚至还包括行业趋势的押注。就基本盘来看Java和Python这两门语言在各自擅长的领域表现得都还不错，不过也相互向对方擅长的领域进行试探（这里的Java泛指JVM系列语言，包括但不限于Groovy、Scala、Kotlin）。之前Java和C#不也是这样相互试探，互摸过河的吗？
Java社区2020年发布了JDK14和JDK15两个版本，但是目前国内使用Java的群体，大都使用的是JDK8或以下版本，将JDK11应用于生产环境的组织还是少数（但越来越多），即使使用Oracle JDK 11完成的系统开发大多也会运行在OpenJDK环境下。这主要的原因还是由于大家关注的主要是JDK的LTS版本，而JDK8和JDK11这两个LTS版本，Oracle分别承诺会一直提供更新支撑到2030年和2026年（但还需要注意OpenJDK相关停更时间）。如果读者所在组织依然还在使用JDK8以前的版本，这里建议可以至少升级到JDK8了。
20年发布的JDK14和JDK15两个版本，虽然不是TLS版本，但是作为JDK17 LTS发布前的特性预览，大家可以通过这两个版本中发布的各种重要特性窥探到Oracle对于Java后续发的规划思路。
从JDK 9开始，Oracle JDK每半年就会更新一次，每次发布新的Oracle JDK后其对应的Open JDK也会随之进行半年时间的更新。
在JDK 14、JDK 15两个版本中个人觉得比较重要的几个特性更新包括：
1. 关于垃圾回收器的更新：
CMS垃圾回收器正式被剔除，ParallelScavenge + SerialOld GC 的组合模式被弃用，ZGC垃圾回收器转正，G1回收器得到优化后依然是默认的垃圾回收器。
2. 关于模式匹配语法的使用：
模式匹配语法已经是连续两次发布预览版本，那么大概率会作为正式特性出现在JDK17版本中。匹配模式是对instanceof修饰符的语法优化。
3. 关于NullPointerExceptions异常的完善：
更完善的NullPointerExceptions异常将快速帮助使用者定位出现空指针的位置，既是使用多个连续方法进行调用时，也可以快速定位。
4. 依赖封闭/接口封闭：
实际上接口封闭功能在JDK15之前的版本就有内部应用，这个版本只是将接口封闭功能作为预览特性提供给最终使用者使用。个人估计在稳定的JDK17版本中，该特性大概率会作为正式特性被发布。
5. record紧凑语法：
该特性也已经连续两次发布预览版本了，也是大概率会作为正式特性在JDK17版本中进行发布。个人疑惑，紧凑语法不会是Oracle团队借鉴了Lombok的功能特色吧！
★ Spring Boot更新
2020年11月，Spring Boot发布了2.4.0版本，这是一个GA版本也就是正式发布版本，而且Spring Cloud也做了对应匹配的更新。2.4.0版本开始支持JDK15的特性，但这个版本并不建议各位在正式环境立即更新。
实际上Spring Boot今年一共维护了两个大版本2.3.1——2.3.6版本，以及2.4.1版本。作者目前在实际工作中使用最多的版本还是2.2.X的版本，而2.3.X的版本在最新的几个项目中也有采用。从Spring 2.3.X版本开始，Spring Boot的构建方式从Maven切换到了Gradle，这个是笔者之前的猜想是一样的，作者在几年前就在项目构建过程中力推使用Gradle，并且在实施过程中得到很好的效果证明。
Gradle在多年前的使用份额上，已经有快速追平Maven的趋势，而Spring Boot的新版本采用Gradle进行构建后，势必会为Gradle的推广起到正面示范效果。
★ Spring Cloud更新
随着Spring Boot的更新，Spring Cloud也发布了新的版本。2020年Spring Cloud发布了2020.0版本，该版本并没有再使用之前Spring Cloud版本的命名方式（上一个Spring Cloud的版本命名为Hoxton，这些版本名都是以英国伦敦地铁站进行的命名），新版本采用日历化版本命名为2020.0.X。该版本中正式去掉了多个netflix集成的组件，例如netflix-hystrix、netflix-ribbon、netflix-zuul、netflix-turbine，只有netflix eureka得以保留（并且已经不推荐使用），可见netflix在Spring Cloud的新版本中所占比重已经是是越来越低了。
实际上Spring Cloud替换netflix各个组件的动作在之前的版本中已逐渐清晰，Spring Cloud官方也给出多个组件的替换方案（列举这些替换方案后，可以看到，Spring大社区的技术栈更新真的很快，稍不留神就容易遗漏更新，再稍不留神就容易内卷）：
1. 服务注册中心：
Nacos，来自于SpringCloudAlibaba，之前如果已经在项目中使用的Consul，那么建议继续使用；如果是新的项目或产品，建议切换到Nacos上来；其它还在支持的组件包括zookeeper、Consul；Eureka已经不建议使用，如果仍然在项目或者产品上使用，则可以考虑以最小的技术代价尽快完成升级。个人认为Nacos之所以会后来居上，它的集成度很高，显著减少了使用者的学习成本是很重要的一个方面
2. 服务调用：
openFegin，有的读者容易混淆openFegin和Fegin，这两者不是一回事，Fegin是netflix提供给Spring社区的组件，目前已被openFegin替换掉
3. 调用负载：
LoadBalancer，在新版本中已经正式替换掉Ribbon
4. 熔断与升降级：
Resilience4J和Sentienl都是最新版本中官方推荐的可选版本，其中Sentienl来源于SpringCloudAlibaba，国内的使用资料和讨论资料也更多一些，建议可以使用Sentienl替换Hystrix，当然，如果读者所在组织的替换成本比较高，那么建议可以分步骤进行，毕竟Hystrix之前存在了较长一段时间
5. 服务网关：
实际上个人来说，之前各个项目和产品中使用zuul还是用得比较顺手的，但后面随着更多的产品和项目的研发执行，作者也开始转向gateway的使用。确实好用，推荐使用
6. 服务配置：
Config组件依然存在于Spring Cloud的最新版本中，但如果读者所在组织使用的是Nacos，那么建议可以使用Nacos进行功能替换
其余不再列举，总结一下Spring Cloud的发展趋势：组件集成度逐渐升高，初始版本中由netflix提供的各种组件已被逐步移除（主要原因是后者更新频度无法满足Spring社区的要求），SpringCloudAlibaba提供的组件在Spring社区所占份额逐步提升，甚至可以猜测不久的将来SpringCloudAlibaba和原生Spring Cloud两者的技术线路会逐步合并。实际上读者直接使用SpringCloudAlibaba就是一个不错的选择
1. IDE工具更新：
Eclipse最近几年使用份额掉的非常厉害，最主要的原因就是大多数开发人员转向了 Intellij IDEA，虽然后者的商用版是付费的，但并不影响开发人员的使用热情（你懂的）。不过个人认为Eclipse和IDEA两个主要的开发工具并没有谁绝对胜出的说法，厂商支持和社区活跃度起到了主要的影响作用，选择哪个工具还是看个人喜好，毕竟想靠换一个工具就get新技能的想法有些幼稚。
2020年12月Intellij发布了IDEA的最新版本2020.3（包括多个编辑器），这样一来2020年Intellij IDEA一共就发布了3个可用版本。这个版本新增/修改了多个特性，包括：
欢迎页发生了明显的变化，在欢迎页上新增了学习选项卡，以便于使用者对IDEA的使用学习。
IDEA对Git的支持已经非常完整了，直接将Git选项集成到了顶层菜单中，并且在搜索选项卡中新增了单独的Git搜索结果项。
其它优化项诸如代码表情、阅读器模式、调试功能改进、性能分析器、内存快照等等。
2. Centos 8 将很快停止维护
CentOS 8将于2021年停止更新，不过CentOS 7还是会支撑到2024年，所以目前使用量最大的CentOS 7版本的用户暂时不会受到影响。另外CentOS 8 停止更新后，使用者可以选用CentOS Stream 8在非生产环境进行替换。不过，个人认为最好的选择是直接切换到Ubuntu server。
3. 企业应用方面，中台化大行其道
小前台、大中台实际上是阿里2015年开始在内部推行的技术战略，到了18年各个行业看着阿里的成功经验后也开始逐步解决这样的资源集中化解决方案。零售、物流、快消品、耐消品、互金等等行业，都有一批企业开始试行中台化线路。还有一批IT企业也开始精耕于企业级中台化解决方案，并向客户大肆宣传自己的成功案例。但是真的所有企业都适合做中台吗？笔者持怀疑态度。要知道阿里所宣推的中台，也只是电商行业的中台，简称电商中台。
单纯从技术层面来考虑，中台化战略涉及到对企业中若干系统的整合问题，但并不是所有企业都具有阿里那样快速的系统迭代特性，就笔者个人所接触的客户，一些客户还在使用10年前的老系统，这些系统的集成将是比较困难的技术问题；从业务层面考虑，并不是所有的企业都有几十个业务系统，上千个业务流程，对单一几个系统的中台化是否可以达到简化业务的目的？从IT团队人力资源的角度看，算了，不看了。
一年的时间又过去了，疫情的影响无论是对个人还是行业都是很明显的，程序员应该要多多考虑如何避免内卷的问题，要多多考虑自身抵御风险的能力，不要在舒适区待得太久。
2021，与君共勉。
「
2000GB视频教程+面试资料
免费领取了
关注下面的公众号 回复关键词【资料】
👆关注公众号回复关键词【资料】二字👆
👆获取2000GB教程资料下载👆
往期推荐