Java 17 采用率增长 430%、Java 11 稳居第一,最新 Java 编程语言报告来了!

2023-08-08 09:25:29 浏览数 (2)

1995 年,Sun Microsystem 公司发布了 Java 程序设计语言,为开发现代多媒体应用程序提供了一种更加可移植和交互的方式。从那时起,Java 便成为主流的编程语言之一,被应用于各行各业,也有着“一次编写,到处运行”的优势特性。

近日,为揭晓 Java 生态系统的最新发展状况,分析公司 New Relic 在调研了新版本、容器应用、垃圾回收等特性之后,最新发布了《2023 年 Java 生态系统现状》报告。

在本文中,我们将与大家共同深入了解这门被广泛应用的编程语言。

Java 17 的采用率在一年内增长了 430%

众所周知,Java 版本分为长期支持(LTS)和短期支持支持版本。一般长期支持的版本都比较稳定,或者官方会不断更新补丁包。短期支持版本只是作为过渡版存在。

自 2017 年 Oracle 将 Java 版本的更新频率更改为六个月一次时,长期支持 LTS 版本大概 2-3 年更新一次。不过,这种高频的更新率让无数网友怨声载道,学不动的声音不绝于耳,以至于很多人呈现出“你更任你更,我不用”的“摆烂”状态。

这不,Oracle 在今年 3 月最新发布了 Java 20 版本。不过,据最新数据报告显示,Java 11 已连续两年位居榜首,成为开发者最常用的 Java 版本。

当下,超过 56% 的应用程序在生产中使用 Java 11,这一比例要高于 2022 年的 48% 和 2020 年的 11%。

Java 8 的使用率紧随其后,近 33% 的应用程序在生产中使用它(低于 2022 年的 46%)。

虽然 Java 11 稳居第一,但是最新的 LTS 版本 Java 17 的采用率逐年攀升,从去年不到 1% 的比例,迅速增长至今年的超过 9% 的占比。研究报告显示,Java 17 在过去一年内增长率为 430%,而彼时 Java 11 花了数年时间才达到那个水平。

相较之下,只有 0.28% 的应用程序仍在生产中使用 Java 7。这并非没有根由,究其原因,是因为官方对 Java 7 的支持已于 2022 年结束。大多数使用 Java 7 的应用程序都是尚未升级的遗留应用程序。

与 LTS 版本相比,短期的非 LTS Java 版本的使用率仍然极低,只有 1.6% 的应用程序使用非 LTS Java 版本(低于 2022 年的 2.7%)。

根据报告调研发现,可能导致影响非 LTS 版本使用率下降的一些因素包括:

  • 缺乏支持
  • 缺乏吸引力的新功能
  • 距离下一个 LTS 版本发布的时间太短

曾几何时,Java 8 发布了之后,外界并不能知晓下一个 LTS 版本 Java 11 会什么时候发布。不过,后来 ,Oracle 明确做出承诺:六个月一次更新,自此大家都有了清晰的认知,自然宁愿等等下一个 LTS 版本,也不愿在生产环境使用不稳定的非 LTS 版本。

数据显示,在使用的非 LTS Java 版本中,Java 14 仍然是最受欢迎的,占比0.57%(低于 2022 年的 0.95%),Java 15 紧随其后(0.44%,低于 2022 年的 0.70%)。

亚马逊现在是最受欢迎的 JDK 供应商

近年来,使用的 Java Developer Kit (JDK) 发行版的源代码发生了变化。过去,很多开发人员常常从 Oracle 获得他们的 JDK,但是 Oracle JDK 后来针对商业应用采取收费政策,这也让很多人望而却步,好在 OpenJDK 项目日渐丰富,成为众人的选择。

调查数据显示,2020 年,Oracle 是最受欢迎的 JDK 供应商,约占 Java 市场的 75%。在其 JDK 11 发行版的许可更严格之后(在 Java 17 回归更开放的立场之前),业界开发者开始逐渐远离 Oracle。虽然 Oracle 在 2022 年以 34% 的份额保持榜首,但在 2023 年下滑至 28%。

与之形成鲜明对比的是,Amazon 的使用率急剧上升至 31% 的市场份额(从2020 年的 2.18% 和 2022 年的 22%),使其成为最受欢迎的 JDK 供应商。

容器化应用程序已成为主流,据 New Relic 调研显示,70% 的 Java 应用来自容器。

容器会影响工程团队分配计算和内存资源的方式。例如,New Relic 数据显示,在容器中运行的应用程序少于 4core 的比例要高得多。

工程团队正在摆脱容器中的单核设置,只有 36% 在使用(低于 2022 年的 42%),并转向多核设置,超过 29% 使用 8core 设置(高于 2022 年的 20%)。

工程团队通常在他们经常部署容器的云环境中使用较小的计算设置。但是,这种趋势可能会给某些应用程序带来意想不到的问题,这可能会导致配置减少。例如,如果团队只使用一个 CPU,他们可能得不到他们期望的垃圾收集器——即使他们明确地设置了它。

自动垃圾收集是查看堆内存、识别哪些对象正在使用、哪些未使用以及删除未使用对象的过程。 鉴于其在 JVM 性能中的核心作用,垃圾回收仍然是 Java 社区中的热门话题。

New Relic 数据显示,Garbage-First (G1) 垃圾收集器仍然是使用 Java 11 或更高版本的用户的最爱,65% 的客户使用它。G1 的主要好处之一是,它清除较小的区域而不是一次性清除大区域,从而优化了收集过程。它还很少冻结执行并且可以同时收集年轻代和老年代,这使它成为工程师的一个很好的默认设置。

其他在 Java 8 之后出现的实验性垃圾收集器(ZGC 和 Shenandoah)在生产系统中的使用仍然很少。两者都有生产就绪版本,但在一般处理中仍然可以忽略不计。

完整的报告内容详见:https://newrelic.com/sites/default/files/2023-04/new-relic-2023-state-of-the-java-ecosystem-2023-04-20.pdf

0 人点赞