vlambda博客
学习文章列表

Java 已老矣,生态却依旧!

站在编程语言的长河中,看过去一年 Java 的发展。

作者 | 说好不能打脸,CSDN 博客专家
责编 | 张文
头图 | CSDN 下载自视觉中国
出品 | CSDN(ID:CSDNnews)
2020 年结束,知名编程语言社区 TIOBE 对于各种编程语言排名情况的总结是:“Python is TIOBE’s Programming Language of 2020”。 这无疑是对我自己这个写了 20 年 Java 程序的老码农相当有震撼力的一句话。
曾经自己调侃 Delphi、调侃 Ruby 的样子,和近些年自己被调侃的样子极为相似。
Python 的快速发展、Java 的被赶超、Ruby 的夕阳余晖有其语言自身的因素,也有各大厂商推波助澜的因素,还有其生态圈发展情况等等因素。但笔者认为那些都是表面现象,最大影响因素是由社会对信息化应用、数字化应用的需求所决定的。
一门高级语言是不是有活力,主要是看它能不能低成本解决各行业对各类软件方案进行快速复制的要求。这些成本可以包括人力资源、单位时效、需求匹配度、行业所需的运行效能各个方面。
而作为程序员,特别是生活在当前物质环境下的程序员,我们对于一门语言的选择往往取决于建立在此基础上的下一维度的考量,例如就业机会如何、学习成本如何、薪资水平如何、持续性如何、内卷风险如何甚至还包括行业趋势的押注。就基本盘来看 Java 和 Python 这两门语言在各自擅长的领域表现得都还不错,不过也相互向对方擅长的领域进行试探(这里的 Java 泛指 JVM 系列语言,包括但不限于 Groovy、Scala、Kotlin)。之前 Java 和 C#不也是这样相互试探,互摸过河的吗?
Java 已老矣,生态却依旧!


Java 已老矣,生态却依旧!

关于 Java 版本


Java 社区在 2020 年中发布了 JDK14 和 JDK15 两个版本,但是目前国内使用 Java 的群体,大都使用的是 JDK 8 或以下版本,将 JDK 11 应用于生产环境的组织还是少数(但越来越多),即使使用 Oracle JDK 11 完成的系统开发大多也会运行在 OpenJDK 环境下。
这主要的原因还是由于大家关注的主要是 JDK 的 LTS 版本,而 JDK8 和 JDK11 这两个 LTS 版本,Oracle 分别承诺会一直提供更新支撑到 2030 年和 2026 年(但还需要注意 OpenJDK 相关停更时间)。如果读者所在组织依然还在使用 JDK8 以前的版本,这里建议可以至少升级到 JDK8 了。
此前发布的 JDK14 和 JDK15 两个版本,虽然不是 TLS 版本,但是作为 JDK17 LTS 发布前的特性预览,大家可以通过这两个版本中发布的各种重要特性窥探到 Oracle 对于 Java 后续发的规划思路。
从 JDK 9 开始,Oracle JDK 每半年就会更新一次,每次发布新的 Oracle JDK 后其对应的 Open JDK 也会随之进行半年时间的更新。
Java 已老矣,生态却依旧!
在 JDK 14、JDK 15 两个版本中个人觉得比较重要的几个特性更新包括:
  • 关于垃圾回收器的更新:CMS 垃圾回收器正式被剔除,ParallelScavenge + SerialOld GC 的组合模式被弃用,ZGC 垃圾回收器转正,G1 回收器得到优化后依然是默认的垃圾回收器。

  • 关于模式匹配语法的使用:模式匹配语法已经是连续两次发布预览版本,那么大概率会作为正式特性出现在 JDK17 版本中。匹配模式是对 instanceof 修饰符的语法优化。

  • 关于 NullPointerExceptions 异常的完善更完善的 NullPointerExceptions 异常将快速帮助使用者定位出现空指针的位置,既是使用多个连续方法进行调用时,也可以快速定位。

  • 依赖封闭/接口封闭实际上接口封闭功能在 JDK15 之前的版本就有内部应用,这个版本只是将接口封闭功能作为预览特性提供给最终使用者使用。个人估计在稳定的 JDK17 版本中,该特性大概率会作为正式特性被发布。

  • record 紧凑语法该特性也已经连续两次发布预览版本了,也是大概率会作为正式特性在 JDK17 版本中进行发布。个人疑惑,紧凑语法不会是 Oracle 团队借鉴了 Lombok 的功能特色吧~~


Java 已老矣,生态却依旧!

Spring 生态


2.1、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 的推广起到正面示范效果。
Java 已老矣,生态却依旧!
2.2、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 大社区的技术栈更新真的很快,稍不留神就容易遗漏更新,再稍不留神就容易内卷):
  • 服务注册中心:
    Nacos,来自于 SpringCloudAlibaba,之前如果已经在项目中使用的 Consul,那么建议继续使用;如果是新的项目或产品,建议切换到 Nacos 上来;其它还在支持的组件包括 zookeeper、Consul;Eureka 已经不建议使用,如果仍然在项目或者产品上使用,则可以考虑以最小的技术代价尽快完成升级。个人认为 Nacos 之所以会后来居上,它的集成度很高,显著减少了使用者的学习成本是很重要的一个方面
  • 服务调用:
    openFegin,有的读者容易混淆 openFegin 和 Fegin,这两者不是一回事,Fegin 是 netflix 提供给 Spring 社区的组件,目前已被 openFegin 替换掉
  • 调用负载:
    LoadBalancer,在新版本中已经正式替换掉 Ribbon
  • 熔断与升降级:
    Resilience4J 和 Sentienl 都是最新版本中官方推荐的可选版本,其中 Sentienl 来源于 SpringCloudAlibaba,国内的使用资料和讨论资料也更多一些,建议可以使用 Sentienl 替换 Hystrix,当然,如果读者所在组织的替换成本比较高,那么建议可以分步骤进行,毕竟 Hystrix 之前存在了较长一段时间
  • 服务网关:
    实际上个人来说,之前各个项目和产品中使用 zuul 还是用得比较顺手的,但后面随着更多的产品和项目的研发执行,作者也开始转向 gateway 的使用。确实好用,推荐使用
  • 服务配置:Config 组件依然存在于 Spring Cloud 的最新版本中,但如果读者所在组织使用的是 Naos,那么建议可以使用 Nacos 进行功能替换
其余不再列举,总结一下 Spring Cloud 的发展趋势:组件集成度逐渐升高,初始版本中由 netflix 提供的各种组件已被逐步移除(主要原因是后者更新频度无法满足 Spring 社区的要求),SpringCloudAlibaba 提供的组件在 Spring 社区所占份额逐步提升,甚至可以猜测不久的将来 SpringCloudAlibaba 和原生 Spring Cloud 两者的技术线路会逐步合并。实际上读者直接使用 SpringCloudAlibaba 就是一个不错的选择


Java 已老矣,生态却依旧!

Java 周边动态


3.1、IDE 工具更新

Eclipse 最近几年使用份额掉的非常厉害,最主要的原因就是大多数开发人员转向了 Intellij IDEA,虽然后者的商用版是付费的,但并不影响开发人员的使用热情。不过个人认为 Eclipse 和 IDEA 两个主要的开发工具并没有谁绝对胜出的说法,厂商支持和社区活跃度起到了主要的影响作用,选择哪个工具还是看个人喜好,毕竟想靠换一个工具就 get 新技能的想法有些幼稚。
2020 年 12 月 Intellij 发布了 IDEA 的最新版本 2020.3(包括多个编辑器),这样一来 2020 年 Intellij IDEA 一共就发布了 3 个可用版本。这个版本新增/修改了多个特性,包括:
  • 欢迎页发生了明显的变化,在欢迎页上新增了学习选项卡,以便于使用者对 IDEA 的使用学习。
  • IDEA 对 Git 的支持已经非常完整了,直接将 Git 选项集成到了顶层菜单中,并且在搜索选项卡中新增了单独的 Git 搜索结果项。
  • 其它优化项诸如代码表情、阅读器模式、调试功能改进、性能分析器、内存快照等等。

Java 已老矣,生态却依旧!

3.2、Centos 8 将很快停止维护

CentOS 8 将于 2021 年停止更新,不过 CentOS 7 还是会支撑到 2024 年,所以目前使用量最大的 CentOS 7 版本的用户暂时不会受到影响。
另外 CentOS 8 停止更新后,使用者可以选用 CentOS Stream 8 在非生产环境进行替换。不过,个人认为最好的选择是直接切换到 Ubuntu server。

3.3、企业应用方面,中台化大行其道

小前台、大中台实际上是阿里 2015 年开始在内部推行的技术战略,到了 2018 年各个行业看着阿里的成功经验后也开始逐步解决这样的资源集中化解决方案。零售、物流、快消品、耐消品、互金等等行业,都有一批企业开始试行中台化线路。还有一批 IT 企业也开始精耕于企业级中台化解决方案,并向客户大肆宣传自己的成功案例。但是真的所有企业都适合做中台吗?
笔者持怀疑态度。要知道阿里所宣推的中台,也只是电商行业的中台,简称电商中台。
单纯从技术层面来考虑,中台化战略涉及到对企业中若干系统的整合问题,但并不是所有企业都具有阿里那样快速的系统迭代特性,就笔者个人所接触的客户,一些客户还在使用 10 年前的老系统,这些系统的集成将是比较困难的技术问题;从业务层面考虑,并不是所有的企业都有几十个业务系统,上千个业务流程,对单一几个系统的中台化是否可以达到简化业务的目的?从 IT 团队人力资源的角度看,算了,不看了。
一年的时间转瞬已过去,疫情的影响无论是对个人还是行业都是很明显的,程序员应该要多多考虑如何避免内卷的问题,要多多考虑自身抵御风险的能力,不要在舒适区待得太久。
2021,与君共勉。

本文来自 CSDN 博客:https://yinwj.blog.csdn.net/article/details/112424912,转载请注明出处。
Java 已老矣,生态却依旧!

Java 已老矣,生态却依旧!

    
      
      
    



Java 已老矣,生态却依旧!
Java 已老矣,生态却依旧!
在看