观点：Scala会成为新的EJB 2吗？

清疚 2022-06-17 10:06 174阅读 0赞

本文来源于我在InfoQ中文站翻译的文章，原文地址是：http://www.infoq.com/cn/news/2011/12/scala-ejb2

近日，Joda Time库的开发者与[JSR 310][] Java语言日期时间改进的规范领导Stephen Colebourne就Scala语言的适用性发表了一篇[令人深思的文章][Link 1]。他比较了Scala与EJB 2，并认为EJB 2是Java EE规范的低谷。

> ...大量的样板代码、XML和复杂性已经渗透到了Java产业中。规范已被广泛采纳，但与这种采纳相伴的却是批评。开发者发现虽然EJB 2试图通过抽象的更高层的API来降低构建企业应用的复杂性，但事实上，它却增加了更多的复杂性，并且没有获得预期的结果。

虽然他偏爱[Fantom语言][Fantom]——但也对其他语言如Kotlin、Groovy和Ceylon充满了好感——他认为Scala并不适合于未来的发展。

他感到不爽的一个地方就是Scala并未提供合适的模块化系统。他说Java一开始也没有提供模块化系统（目前依旧没有，但至少这是现在人们普遍存在的一个需求），只能通过其他手段如Maven、Ivy和OSGi等达成。然而，那些忽视模块化系统的人还是会给需要的人带来麻烦；在处理大型系统时，模块化将成为重要的维护工具。

Stephen还表示假如Java有模块化系统，那么就可以发布不支持CORBA的JVM了，CORBA是个遗留技术，在Java领域中，除了RMI外现在已经很少使用了（对于服务器间的通讯来说，CORBA已经逐步被SOAP和REST所取代）。

事实上，两年前就有人提出了[关于模块化的提案][Link 2]，但很快就被束之高阁。对于模块与版本存在很[严重的阻力][Link 3]（每个模块系统都需要依赖他们来运作）。在那时，[Scala尚未进入到企业][Scala]；两年过去了，Scala的境况依然如故。

Stephen还指出类型系统过于复杂了，在这一点上，他认同[Steve Yegge][]的观点：

> 语言规范，天哪，我简直无话可说了。我必须得在博客上写点什么才行。规范中大约90%的内容都是关于类型系统。这将是你有生之年所能见到的最大的类型系统，其复杂程度并不是一个数量级，甚至能达到5个量级。除了类型就是类型，然后还是类型；太复杂了。  
>   
> 他们称其为complexity complexity ，这意味着它并不仅仅是complexity的问题；也不是complexity-complexity的问题：而是参数化的complexity-complexity，我要说的是这种东西就是在类型上堆积类型，然后再不断地堆积类型，太糙了吧。

Stephen还重点强调了类型签名——一开始用于表示方法能够正确编译——现在变得越来越没有意义了，甚至在支持Unicode方法前就这样了。他给出了如下的方法签名，来自于Scala核心库，他想知道这个方法到底是干啥的：

> def ++ \[B >: A, That\] (that: TraversableOnce\[B\])(implicit bf: CanBuildFrom\[List\[A\], B, That\]) : That

事实上，Stephen认为使用静态类型会给静态类型蒙羞：

> 我想说的是，这个庞大的类型系统目的在于防止编译错误，并且对代码进行预检查。但要是将这种逻辑放到动态类型系统的语言中就不行了。对于我来说，Scala的类型系统已经背离了语言特性的本质。  
>   
> 本质上，Scala的类型系统给静态类型蒙羞了。

上面这些并不是什么新观点。Log4J与SLF4J项目的创建者Ceki Gülcü就在问[Scala是否值得信任][Scala 1]，因为这门语言已经演化了很多，多次违背了向后兼容性（未来也不见得会解决这个问题）：

> 然而，Scala语言有一点让我颇为不爽。每次新版本发布时，Scala都破坏了二进制兼容性。尽管之前做过许诺，但2.7版依然破坏了兼容性，2.8版又是这样，2.9也不例外。我清楚这一点，当Scala库的特性以一种不兼容的方式发生变化时，Scala语言的设计者也只能置兼容性于不顾了。

将Ceki的观点展开，在Java出现前，要想在不同操作系统和版本间实现可移植性，从源代码进行编译是不二之选。直到标准C ABI出现后，我们才可以在相同操作系统的不同版本间使用相同的二进制文件，最终导致了诸如Debian、RedHat和Ubuntu等二进制发布包的出现。由于缺少这些ABI，很多公司都无法在早期的Linux内核1.x和操作系统上安装其商业产品的二进制版本（他们当然不想共享源代码了）。

Ceki进一步说到“相互竞争的语言间的差距最终将会缩小，Scala也将不会像现在这么酷了”。在一开始，Scala有机会激发众多Java程序员的想象力。它诱使那些想要学习函数式编程的程序员们学习它，同时Scala又提供了更为简洁的代码。但由于一次又一次地将语言稳定性这一要义抛之脑后，同时又沿用几年前Java所用的那些手段（但却忽视了Java在各个版本间的兼容性），这一切都使得Scala游走于主流企业项目的边缘地带。没错，一开始是有些团队采用Scala并获得成功，但到目前为止，我还没听说哪个团队能够在一两年后还能继续维护好Scala代码基。

现在，有不少基于JVM的语言都值得我们去探索，从Fantom到[Xtend][]，这些语言正在不断蚕食Scala的地位。甚至连Java都要在下一版本中提供模块化和lambda了；虽然被推迟了一年多，但将函数式编程带到Java中肯定要比Scala达到稳定快得多。在Scala步入正轨前Java将会迎头赶上。Scala，你太晚了。

**查看英文原文：**[Opinion: Is Scala the new EJB 2?][Opinion_ Is Scala the new EJB 2]

[JSR 310]: http://jcp.org/en/jsr/detail?id=310
[Link 1]: http://blog.joda.org/2011/11/scala-feels-like-ejb-2-and-other.html
[Fantom]: http://fantom.org/
[Link 2]: http://alblue.bandlem.com/2009/08/modularity-for-scala.html
[Link 3]: http://permalink.gmane.org/gmane.comp.lang.scala.internals/1710
[Scala]: http://alblue.bandlem.com/2009/10/scala-is-still-not-enterprise-ready.html
[Steve Yegge]: http://steve-yegge.blogspot.com/2008/06/rhinos-and-tigers.html
[Scala 1]: http://ceki.blogspot.com/2011/08/is-scala-trustworthy.html
[Xtend]: http://xtend-lang.org/
[Opinion_ Is Scala the new EJB 2]: http://www.infoq.com/news/2011/11/scala-ejb2