混合Scala/Java项目中优先选择Java而非Scala的场景有哪些

在Spark、Kafka这类以Scala为主要开发语言的项目中，选择用Java开发特定模块的核心逻辑都围绕兼容性、性能可控性、生态适配、维护成本四个维度展开，典型场景如下：

• 对外暴露的公共API/SDK模块
  Scala不同大版本（2.11/2.12/2.13）之间字节码互不兼容，甚至小版本迭代都可能出现符号断裂。如果公共接口用Scala实现，使用者就必须和项目使用完全一致的Scala版本，对纯Java用户也极不友好。
  比如Kafka的客户端SDK、Spark的对外Java API层都采用Java实现，不管使用者用什么Scala版本、甚至是纯Java项目，都可以直接接入，不受Scala版本绑定限制。
• 性能极致敏感的核心底层模块
  Scala的很多语法糖背后存在隐式开销：隐式转换、样例类自动生成的冗余方法、函数对象的自动装箱拆箱、默认不可变集合的额外开销都不可控。对核心执行链路（比如Kafka的消息存储逻辑、Spark的Task执行核心路径）用Java开发，可以完全控制每一行代码的执行开销，避免Scala隐式逻辑带来的性能损耗。
  同时Java的性能 profiling 工具链更加成熟，排查热点、内存泄漏时不会受Scala特有的语法符号干扰，问题定位效率更高。
• 重度依赖Java生态组件的模块
  绝大多数基础中间件（Netty、数据库驱动、加密库等）都是纯Java实现，用Scala调用需要额外做类型适配、集合转换，反而增加代码复杂度。比如Kafka的网络层基于Netty开发，用Java实现可以无缝对接Netty API，没有任何适配成本。
  针对Java生态的适配模块（比如Spark对接Hadoop组件的适配层）用Java开发，也可以避免两边的类型、版本冲突。
• 需要降低社区贡献门槛的模块
  Scala的学习曲线远高于Java，大部分JVM开发者仅掌握Java技能。项目的周边模块（比如插件接口、开发示例、工具组件）用Java实现，可以吸引更多Java背景的开发者参与贡献，扩大社区参与度。比如Spark的插件开发框架、Kafka的连接器API都优先提供Java版本的实现和示例。
• 稳定运行的历史遗留模块
  很多项目早期为纯Java开发，后续才引入Scala开发上层业务逻辑。底层已经稳定跑了多年、无明显bug的Java模块完全没有必要用Scala重写，重写反而会引入额外的不稳定因素，这类模块会一直沿用Java实现长期维护。

补充说明：混合语言开发都是收益高于成本时的选择，正常业务逻辑用Scala的开发效率远高于Java，不会刻意切换到Java实现。

内容的提问来源于stack exchange，提问作者Mrinal