为什么 Flink 抛弃了 Scala

曾经红遍一时的Scala

想当初Spark横空出世之后,Scala简直就是语言界的一颗璀璨新星,惹得大家纷纷侧目,连Kafka这类技术框架也选择用Scala语言进行开发重构。

可如今,Flink竟然公开宣布弃用Scala

在Flink1.18的官方文档里,有一句非常严肃的话:所有的Flink Scala APIs已被标记为废弃,且将在未来版本中予以移除。

复制代码
All Flink Scala APIs are deprecated and will be removed in a future Flink version. You can still build your application in Scala, but you should move to the Java version of either the DataStream and/or Table API.

See FLIP-265 Deprecate and remove Scala API support

究竟为何Flink舍弃Scala?

为了一探究竟,我特地研究了FLIP-265 Deprecate and remove Scala API support的文档,其中内容如下。

Flink通过APIs方式来构建DataStream和TableAPI程序。这些是用Java和Scala写的。PythonAPI在底层使用JavaAPI。随着时间的推移,Flink社区的主要焦点已经转向JavaAPI,而Flink中的Scala支持与JavaAPI并不同步。举几个例子:

复制代码
Flink仍然仅支持Scala2.12.7,如果要升级的画,只能通过破坏兼容性升级到更高版本
截止到目前为止,Flink还不支持Scala2.13
与Scala中的DataStreamAPI 相比,Java中的DataStreamAPI具有更多可用功能。例如Async I/O

Flink中Scala现状可以总结为( 机翻 ):

复制代码
大多数与Scala相关的贡献都集中在阻止用户在任何Scala版本中使用JavaAPI
Flink社区缺乏具有Scala知识的维护人员,可以帮助直接在Flink中转发Scala支持
添加到Flink的新API接口首先是为Java创建的,在Scala中没有或只有有限的支持
开源社区正在制定举措来帮助Flink中的Scala支持,例如https://github.com/ariskk/flink4s(为Scala3用户包装JavaAPI)和https://github.com/findify/flink-adt(取代了flink-scala 中的TypeInformation派生机制)

至于Scala版本之间的兼容性为何总是那么差,其实很简单:

当年Scala刚创出个头角时,并未面临着保持兼容性的压力,因为那时的它并不吃香,也未受到大型企业的青睐。正是这种无人关注的状态,使得维持兼容性变得无所谓。直至Scala 2.7.x版本前后,它开始呈现出崛起之势,一些新兴企业,比如Twitter,纷纷将其作为首选,由此一来,向后兼容性才成了头等大事。

在Scala 2.8.0开始起航之时,该语言引入了一套特殊规则以最大程度上保持兼容性。对于Scala2来说,版本划分更为明确:2.major.minor,只要主版本保持不变,次要版本之间就能做到完美兼容。主版本的跨越往往会破坏二进制兼容性,也就意味着编译生成的目标代码可能存在差异。

我曾与业界大佬咨询过这个问题,他的回答是:主版本跨度导致二进制兼容性遭受破坏的根本原因在于,JVM字节码并不是特别为Scala而生的,而是专为Java量身定做。当Scala引入新的特性时,JVM并不会主动调整以支持这些新功能,因此Scala必须在编译器生成的字节码中实现,

另外,当呼声极高的Java8集锦登场之际,Java和JVM携手新增了诸多新功能,这些新功能需要改变 Scala的执行机制,以便更好地与Java8代码相互融合,这也破坏了二进制兼容性。

但Scala3将引入一个特定的Scala的中间"字节码",这将允许不同的版本保持彼此的兼容性。

破案

Flink抛弃Scala的主要原因是因为,社区缺少Scala相关的人员,并且新的Api都是Java的,另外因为兼容性问题,Scala和JavaApi的发展并不同步。综上,Flink抛弃Scala

为什么选择Java作为Apache Flink的首选API

选择Java作为Apache Flink的首选API,是因为Java提供了一个稳定可靠的平台,适合大规模的计算和流处理。Java拥有丰富的库和工具,可以帮助开发者更高效地实现各种计算逻辑。此外,Java的生态系统也非常庞大,包含了很多优秀的工具和库,使开发者能够更轻松地开发和维护Flink应用。Java的可移植性和跨平台性也是其受欢迎的原因之一。无论开发者身处何地,他们都可以使用Java开发Flink应用,并且在不同的平台上进行部署和运行。另外,Java社区的活跃程度也是不容忽视的,Java的开发者群体庞大且经验丰富,他们可以为Flink提供宝贵的支持和指导,从而帮助用户更好地使用和优化Flink的功能。总的来说,Apache Flink选择使用Java API,是基于Java的稳定性、可移植性、生态系统、社区活跃度等方面的综合考量

相关推荐
融智兴科技10 分钟前
防伪强度从哪里来?一物一码、动态验证与后台风控
大数据·科技·物联网
财经资讯数据_灵砚智能37 分钟前
基于全球经济类多源新闻的NLP情感分析与数据可视化(夜间-次晨)2026年6月5日
大数据·人工智能·python·ai·信息可视化·自然语言处理·灵砚智能
稳如磐石.1 小时前
北京工业计算机
大数据·人工智能·python·物联网
让学习成为一种生活方式1 小时前
AlkaPlorer:天然生物碱及其衍生物数据库挖掘平台--文献精读240
大数据
2501_912784081 小时前
后端开发实战:反向海淘多币种结算模块自研与SaaS复用对比
大数据·人工智能·taocarts·跨境saas
团象科技1 小时前
走访近百支出海技术团队后的海外云计算资源选型实操观察
大数据·人工智能·算法
2601_957190902 小时前
超元力mr卡丁车:轻量化落地运营,适配中大型场地的新型游乐业态
大数据·人工智能·mr
YangYang9YangYan2 小时前
2026新高考背景下大数据专业报考指南:数据分析的价值与前景
大数据·数据分析·高考
段一凡-华北理工大学2 小时前
工业领域的Hadoop架构学习~系列文章18:制造业Hadoop应用实践 - 从数据到智能的完整闭环
大数据·人工智能·hadoop·分布式·学习·架构·高炉炼铁
属鼠哥2 小时前
HDFS 短路本地读取系列(二):你以为的「本地读」和真正的「本地读」—getLegacy vs getBlockReaderLocal 的本质差异
大数据·hadoop