2022 年团队应该关注的 Java 趋势

来源: OSCHINA
2021-12-02

Java 的发展速度很快,而伴随着 OpenJDK 发布周期的潜在变化,它的发展速度或许还会进一步加快。对于像 Perforce 公司的 JRebel 开发主管 Michael Rasmussen 这样的人来说,紧跟这些变化并了解它们对开发的影响;对于创造能在 Java 开发社区引起共鸣的功能,使应用程序与流行的 Java 技术的最新版本保持同步,以及为 JRebel 开发新的功能、改进和集成,是至关重要的。

外媒 SDTimes 对 Michael 进行了一次采访,详细讨论了团队在 2022 年间应该关注的 Java 趋势。

首先在版本采用规模方面,Michael 称,Java 8 这一版本因为包含了一些重大功能的添加,从而推动了采用率的大幅增长。但反观 Java 17 却并没有如此重大的变化,对于使用 Java 8 的用户来说,迁移到 Java 17 是有很多好处,但也不可能推动团队大规模进行迁移。因此 Java 17 采用规模不可能达到 Java 8 的级别。

而在查看了发布路线图以及各种 Java 增强项目的状态后,Michael 则认为,下一个将在 Java 中看到的重大采用事件将与 Valhalla 项目以及向该语言添加值类型相关。但是,即使考虑到更快的 LTS 发布节奏,Michael 猜测这也是 Java 25 之后的 LTS 版本中的事了。

Michael 指出,有关发布节奏的更改还没有正式确定下来,但考虑到所有大型 OpenJDK 供应商都已加入,LTS 的发布节奏大概率会从每三年改为每两年。此举势必会对 Java 生态系统造成巨大的影响;其中的一个长期影响就是,采用非 LTS 版本用户将越来越少。

“从本质上讲,当你可以等待不到两年的时间来采用具有你所需要的功能的 LTS 版本时,你为什么要采用一个中间版本呢?这并不是说人们不采用非 LTS 版本 — 只是大多数 Java 团队没有能力在发布时升级到最新版本。另一方面,快速发布节奏意味着小升级通常是没有问题的升级。如果你有一个项目,或者你正在启动一个项目,最好是瞄准与预期项目发布相一致的 LTS 版本,并在开发期间使用最新的非 LTS 版本。”

谈到即将于 2022 年发布 Java 18 和 19 时,Michael 则表示,其中值得关注的功能应该是外部函数接口和矢量 API。“我希望这两个功能都能在 Java 19 中被确定下来。在语言方面,我认为我们将继续看到越来越多的模式匹配的增强。”

此外,鉴于 JRebel 每年都会进行一次 Java 行业调查,Michael 表示,今年的报告中展现的技术趋势将包括有:

  • 在框架层面,Micronaut 和 Quarkus 等微服务框架将继续在 Spring Boot 上占据市场份额。然而,考虑到 Spring Framework 6 和 Spring Boot 3 计划在 2022 年下半年发布,因此 Spring 也不会不战而败。新的 Spring 版本需要考虑的另一件事是,它们将针对 Java 17 和 Jakarta EE 9,此举也将可能有助于推动 Java 17 的采用。
  • IDE 方面,IntelliJ IDEA 仍将是使用率最高的一个,但也会有更多地 VSCode 作为次要甚至主要工具。 
展开阅读全文
8 收藏
分享
加载中
精彩评论
java一年一个版本,两年一个LTS是比较合适的,现在的发布速度有点快了,完全没有必要,每次更新都没什么更新,都是小打小闹,刷版本号没有任何意义
2021-12-03 00:57
6
举报
编译成nativecode启动速度大幅提升,但是会丢失很多动态的功能,并且针对不同的平台还要编译出不同的nativecode程序,失去了一次编译到处运行的初衷。
实际上启动后很多代码也都被jit编译成nativecode加速,性能方面没有多大影响,Java强大的jit提供了性能保障,只是丢失了一些启动速度,还有内存占用。
好像graalVM就能打包native
2021-12-02 10:35
3
举报
I_I
1、可以像Go那样交叉编译,在一个平台上编译出多个目标平台的二进制文件。
2、JIT需要预热。大家都起跑了,你却说:等一下,等我热热身!
3、JIT只是将部分代码编译成Native Code,和全部编译成Native Code,哪个性能更好?
4、在运行过程中,JIT判断哪些代码需要编译,以及编译的过程,都是在影响运行的性能和占用资源;
5、编译成Native Code后,JVM就可以彻底丢弃,再也不用什么“JVM从入门到精通”,还能节省一部分硬件资源
6、目前编译成Native Code都不成熟,不是编译过不去,就是编译后运行报错
2021-12-02 11:42
2
举报
I_I
1、可以将JRE打包进去,但体积会比较大,运行起来还是需要JVM,只是那个JVM是你自己带过来的,和PHP将代码文件和运行环境一起打包部署差不多
2、不将JRE打包进去,就得先在目标平台部署,和PHP运行前先搭建运行环境差不多
3、如果想在目标平台发挥最佳性能,最好还得“精通JVM调优”
2021-12-02 12:01
1
举报
最新评论 (15)
高版本都不向下兼容有什么意义呢。 升级JDK版本则现有的Spring依赖全都不兼容。
2021-12-08 09:56
0
回复
举报
java一年一个版本,两年一个LTS是比较合适的,现在的发布速度有点快了,完全没有必要,每次更新都没什么更新,都是小打小闹,刷版本号没有任何意义
2021-12-03 00:57
6
回复
举报
jvm 可以裁剪吗?
2021-12-02 19:55
0
回复
举报
详见java9模块化
2021-12-03 09:28
0
回复
举报
听说 19 要预览 loom l,希望 21 生产支持 loom,但是我还是要说下,能不能给 Java 整个扩展函数啊
2021-12-02 10:43
0
回复
举报
万年Java8
2021-12-02 09:51
0
回复
举报
I_I
Java编译成Native Code不知道什么时候能成熟,彻底摆脱JVM这个龟壳!
2021-12-02 09:02
0
回复
举报
现在倒是有kotlin,但是N多已有包不支持,打包依赖一大堆,和打包GO比还是不够方便
2021-12-02 09:12
0
回复
举报
顶多换个虚拟机,不用了那感觉都不能叫java了
2021-12-02 10:30
0
回复
举报
I_I
编译成Native Code后就跟虚拟机没关系了,部署的时候也不用“精通JVM调优”
2021-12-02 11:46
0
回复
举报
编译成nativecode启动速度大幅提升,但是会丢失很多动态的功能,并且针对不同的平台还要编译出不同的nativecode程序,失去了一次编译到处运行的初衷。
实际上启动后很多代码也都被jit编译成nativecode加速,性能方面没有多大影响,Java强大的jit提供了性能保障,只是丢失了一些启动速度,还有内存占用。
好像graalVM就能打包native
2021-12-02 10:35
3
回复
举报
I_I
1、可以像Go那样交叉编译,在一个平台上编译出多个目标平台的二进制文件。
2、JIT需要预热。大家都起跑了,你却说:等一下,等我热热身!
3、JIT只是将部分代码编译成Native Code,和全部编译成Native Code,哪个性能更好?
4、在运行过程中,JIT判断哪些代码需要编译,以及编译的过程,都是在影响运行的性能和占用资源;
5、编译成Native Code后,JVM就可以彻底丢弃,再也不用什么“JVM从入门到精通”,还能节省一部分硬件资源
6、目前编译成Native Code都不成熟,不是编译过不去,就是编译后运行报错
2021-12-02 11:42
2
回复
举报
大佬讲的有道理,还是希望JAVA编译二进制方便点
2021-12-02 12:11
0
回复
举报
啊?不都和go一样打一个二进制文件吗?
2021-12-02 11:43
0
回复
举报
I_I
1、可以将JRE打包进去,但体积会比较大,运行起来还是需要JVM,只是那个JVM是你自己带过来的,和PHP将代码文件和运行环境一起打包部署差不多
2、不将JRE打包进去,就得先在目标平台部署,和PHP运行前先搭建运行环境差不多
3、如果想在目标平台发挥最佳性能,最好还得“精通JVM调优”
2021-12-02 12:01
1
回复
举报
更多评论
15 评论
8 收藏
分享
返回顶部
顶部