内容简介:本文对 2019 年 Java 和 JVM 生态系统做了一些预测。正如 InfoQ在我们步入 2019 之际,让我们来看看在新的一年中 Java 和相关技术值得注意的点,并试着猜测未来会发生些什么。
本文对 2019 年 Java 和 JVM 生态系统做了一些预测。
正如 InfoQ 2018 年度总结 中说的那样,Java 在 2018 年的发展势头非常有意思。
在我们步入 2019 之际,让我们来看看在新的一年中 Java 和相关技术值得注意的点,并试着猜测未来会发生些什么。
免责声明:以下猜测仅仅是作者个人做出的,并不是来自 Oracle、InfoQ 或其他方面的官方声明或路线图。
Java 11 将出现小规模但意义重大的采用
有关这个预测的争议是最小的。Java 9 和 Java 10 在生产环境中的部署量很小,很多团队似乎都在等待后 Java 8 LTS 版本的发布,现在它来了,Java 11 的采用将会以小而稳的速度开始。
导致 Java 11 被采用的一个推动因素是微服务和容器化的应用程序,使用 Java 11 实现二者都比使用 Java 8 来得容易。在部署全新的应用程序时,Java 11 显然是团队更好的选择。
预测:到 2019 年底,Java 11 安装率将占据 Java 产品安装总量的 10% 左右。
Java 8 应用程序不会大规模迁移到 Java 11
到现在为止,Java 应用程序更新路径都是相对清晰的。从 Java 6 到 Java 7,从 Java 7 到 Java 8,几乎可以说是没有障碍的。但是从 Java 8 到 Java 11 并不是这样的,要将重要的应用程序迁移到新版本需要做大量的工作。
只有很少团队具备足够的资源用于迁移、重构和重新测试应用程序。因此,如果没有足够的外部理由,我不认为今年会有大规模 Java 8 应用程序被迁移到 Java 11 上。
预测:没有具体的可量化预测。
不会出现类似于 Python 2/Python 3 的分裂
很多人已经讨论过这个可能性,即随着 Java 模块化的出现,Java 生态系统可能会出现类似于 Python 社区已经经历过的 Python 2/Python 3 分裂。
但我并不认为会发生这种情况,因为从根本上说,在语法和语义层面,Java 11 并非一门完全不一样的语言。Python 的不同版本之间在语法和关键数据类型(比如说 Unicode 字符串或长整型)方面发生了变化,所以库和应用程序作者必须有意识地选择使用哪个版本,这种选择蔓延到了整个生态系统中。
但对于 Java 来说,应用程序所有者需要决定是否要接受模块化,而库开发人员需要决定是否作为模块进行部署,如果是的话,需要为 Java 8 应用程序提供什么样的回退措施。对 Java 程序员来说,工作大致和之前相同,无论项目是基于 Java 8 还是 Java 11,基本上还是使用相同的语言进行编程。
预测:没有具体的可量化预测。
渐进式的 Graal 采用
已经迁移到 Java 11 的项目可能也会关注 Graal。Graal 提供了下一代 JIT 编译器,新编译器可能会在 2019 年达到(甚至超过)Java 11 的 C2 编译器(即 -server)水平。
Graal-JIT 迟早会超过 C2,Graal 的设计(特别是它是用 Java 实现的)意味着 Graal 团队可以很容易地实现任何 C2 可以实现的新优化。
“Graal”还包含了 Oracle 半开放的多语言运行时 GraalVM。不过需要注意的是,Graal-JIT 仅适用于 Java 11 及以上版本,而 GraalVM 仅涵盖了 Java 8。
因此,Graal 用户社区可能会分为两个部分,一部分关注 Java 11 应用程序的性能,一部分关 Java 8 生态系统的多语言应用程序。
预测:30% 到 40% 的 Java 11 应用程序将在生产环境中使用 Graal-JIT。
讨论是否将 Graal 作为 Java 13 的默认 JIT 编译器,但最后未能实现。
GraalVM 在生产环境的部署还是很少,但会有越来越多的应用程序团队开始尝试使用它。
OpenJDK 成为 Java 运行时的市场领导者
Oracle 宣布终止对 OpenJDK 8 项目的所有权,Red Hat 提出要接管该项目。OpenJDK 11 项目可能也会一样,在 Java 12 发布的时候,Oracle 将会放弃这个项目。
很多开发人员没有注意到 Oracle 的 LTS 产品仅针对付费用户,所以将来对 Java 8(以及 Java 12 发布后的 Java 11 版本)的支持不会是由 Oracle 组织来提供,而是由 Red Hat、Amazon、Azul Systems 以及多厂商和社区驱动的 AdoptOpenJDK 项目 来提供。
由于不再有免费的 Oracle JDK 发布到社区,我预测人们会快速将 OpenJDK 作为 Java 应用程序的生产平台。
好消息是,对于服务器端应用程序(以及越来越多的 Java 桌面程序),OpenJDK 也是 Oracle JDK 的替代品。
预测:到 2019 年底,超过 50% 的 Java 8 和 Java 11 生产运行时会使用 OpenJDK 而不是 Oracle JDK。
Java 12 的发布
Java 12 功能已经确定 ,将在 2019 年 3 月发布。除非有重大事件的发生,否则这次发布会按时进行。
这不是长期支持的版本,不太会被广泛采用(就像 Java 9 和 Java 10 没有被广泛采用一样)。
预测:Java 12 按时发布,并在 2019 年底出现少量的生产部署。
Java 13 发布
Java 13 将在 2019 年 9 月发布。目前对于该版本将包含哪些功能并没有太多相关信息。
和 Java 12 一样,它是一个功能发布版本,并非 LTS 版本。因此,现在没有理由认为它无法按时发布。同样,它也不会被广泛使用,团队会更关注于迁移到 Java 11。
预测:Java 13 按时发布,并在 2019 年底出现少量生产部署。
值类型不会在 Java 13 中预览发布
值类型是除原始类型和对象引用之外的第三种 JVM 基础类型。这个概念可以被认为是放宽了 Java 类型系统规则,可以像 C 语言的结构体那样组合数据结构,同时保证完整的 Java 类型安全。
Java 语言架构师 Brian Goetz 用“ 代码像类,功能像 int ”这样的话来描述他想象该特性发布以后一个典型的开发人员会如何使用值类型。
实现值类型的努力一直在继续,但到 2018 年底,只出现了试验性、非常早期、只有专家使用的测试原型。
这一点也不奇怪,值类型是 Java 平台最根本和最深入的变更之一。
这一功能的复杂度和期望度以及所涉及的大量工程工作使得它不太可能在 2019 年内交付。
预测:即使在 Java 13 预览功能中也不可能出现任何形式的值类型。
match 表达式首个版本将在 Java 13 中预览发布
switch 表达式是 match 表达式的先决条件。如果语法中没有表达式形式,match 表达式也不可能出现在 Java 中。事实上,如果没有 match 表达式,那么引入 switch 表达式也就变得没那么重要。
因此,我预测标准的 switch 表达式推出后,紧随其后会出现简单的 match 表达式。该功能刚开始可能仅限于类型匹配,不包含解构或其他高级功能。
预测:在 Java 13 的预览功能中会包含初始、有限的 match 表达式。
Kotlin 适度增长
来自 JetBrains 的 Kotlin 语言 在最近几年里获得了越来越多开发人员的关注。特别是在 Android 领域出现了爆发式增长,Android 领域的新项目改由 Kotlin 主导。
然而,在服务器端 Java 方面并没有出现类似的爆发性增长。在 2019 年,我预计 Kotlin 的使用会稳定增长,但并不会有大量项目或团队突然转向使用 Kotlin。会有一些高知名度的项目公开使用 Kotlin。
预测:Kotlin 将持续获得 Java 核心社区成员的追捧,但并不会发生爆发式增长,规模还是比 Scala 生态系统小。
一如往常
上面提到了 Java 比较突出的一些变化。然而,在 Java 世界腹地,未来一年中将大致保持不变。Java 的 IDE、库和生态系统的其余部分将大致保持相同。
Java 在业内将继续保持稳固地位和发展趋势,并不会出现什么重大转折。
预测:没有具体的可量化预测。
查看英文原文: Java in 2019 - Some Predictions
以上所述就是小编给大家介绍的《2019 年 Java 和 JVM 生态系统预测:OpenJDK 将成为 Java 运行时市场领导者》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- Zookeeper快速领导者选举原理
- 华能国际:中国电力企业领导者
- Debian 差点无人竞选项目领导者
- Genesys被Forrester评为云联络中心领导者
- 2018中国私有云报告出炉,EasyStack位列领导者象限
- 从码农到架构师,如何成长为技术领导者?
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
RGB转16进制工具
RGB HEX 互转工具
RGB HSV 转换
RGB HSV 互转工具