Scala的一个特性是Scala编译器生成易碎的字节码。 这意味着可执行文件（JAR或WAR）中的所有代码必须使用相同的库和编译器版本进行编译。 如果您在项目中使用Scala 2.9.1，则必须针对根据Scala 2.9.1编译的Lift版本进行编译，并且所有Lift依赖项也必须针对该Scala版本进行编译。 这是Lift几乎没有Scala库依赖项的原因。 这也是Lift泛滥的原因……Lift中有很多模块需要交叉编译，而不是拥有外部模块生态系统，我们需要使它们成为Lift的一部分，以确保它们都针对Lift支持的所有Scala版本。
这个问题的副产品是，几乎不可能针对Scala的预发布版本对Lift或基于Lift的应用进行测试。 这是在任何主要版本发布几周后几乎总是有Scala的“严重错误修复”版本的众多原因之一。 广泛的社区使用Scala库和框架生态系统的第一个机会是在发布之后以及级联的编译/测试/发布之后
一年多以前，在2.8开发周期中，我们中的一些人一起参加了“ Fresh Scala ”项目。 基本上，该想法是将Scala-land的主要图书馆与每周的里程碑进行持续集成，以便社区和生态系统可以对Scala的新版本提供更好的反馈。 由于缺少志愿者时间，我们从未构建过CI系统，在这里，一年半之后，出现了相同的Scala版本易碎性问题，但是事情发生了变化。
Scala不再仅仅是学术和社区活动。 Scala语言和一些相关的库现在是TypeSafe面向企业的套件的一部分。 TypeSafe是一家巨大的（超过20个头）的风险投资公司，应该将Scala带入企业。 但是Scala的版本易损性为复杂的企业类型系统带来了两个巨大的成本：
- 所有依赖项都必须根据完全相同的Scala版本和每个引用的Scala库进行编译，当有多个团队异常复杂或耗时时，它可以进行内部构建
- 外部库（例如Lift）不能具有多层依赖关系，因为您需要完全匹配每个库的确切版本和Scala版本
因此，如果您所在的组织中有两个或三个以上的开发团队都在生成内部Scala代码，则通常可以就Scala的版本以及将要使用的各种库达成一致。 当发布新版本的Scala或库时，您可以将几个人放在一个房间里，然后选择升级（或不升级）。但是一旦超过3个团队，协调工作就变得很重要。 试图让10个不同的团队来协调Scala和Lift，ScalaZ和Rogue和Dispatch等版本将是一笔不小的成本。
作为库构建器，版本易碎性问题意味着我们的库不如应有的那样好，并且我们无法以所需的方式为社区服务。
在为社区提供服务方面，我们无法获得可预测的Lift发行版，因为我们会尝试安排发布时间，以便在新版本的Scala发行后，Lift会很快发行。 鉴于Scala的发布时间表是不可预测的，并且我们需要等待依赖项（例如ScalaCheck和Specs）升级，我们无法回答诸如“何时将取消对Scala 2.8.2的支持？”之类的简单问题。
更重要的是，很少有外部Lift模块，除了Scala和Lift的特定版本以外，它们通常不可用，并且版本不匹配时总会出现问题。 Rogue和Reactive Web等模块可用于一小部分的Lift / Scala版本组合。 有数十个人具有较小的Lift模块，但是对于去年的Scala和Lift版本，它们都没有交叉编译。 这基本上意味着您可以使用Rogue（我建议）或您可以使用Reactive Web（我建议其他），但是您不能在同一项目中使用它们，因为不能保证它们是针对相同版本的Lift和Scala，也无法保证它们会根据您要使用的Scala和Lift版本进行编译。
因此，考虑到Scala版本的易碎性问题，Scala库和框架生态系统的规模将达到最大。 由于在Scala中不可能具有多层库依赖关系，因此将存在诸如Lift之类的整体项目或诸如ScalaZ之类的项目孤岛。 到目前为止，Scala没有足够的本机库和框架来使其具有企业价值。 是的，您可以使用Java库，但是正如其他人所发现的那样，在Scala中包装Java库的成本通常不值得付出成本/精力。
我对该问题做了什么？ 多年来，我已经私下提出了这个问题，但尚未解决。 我已经尝试组织一个项目来解决部分问题，但是还没有志愿者参与该项目。 我曾与Paul Phillips讨论过可以做些什么，Paul， Jevgeni和我甚至设计出了可以集成到Scala编译器中的系统，以解决2010年我们在JVM语言峰会上遇到的问题。 到目前为止，最好的答案是Migration Manager ，这是一个封闭源代码的工具，可以解决一些问题（我没有进行过测试，因为我不会使用任何非OSS软件进行编译或测试Lift来避免任何合法的行为问题。）
我们需要的：
- 我们需要像Scala Fresh这样的东西，以便在Scala生态系统中的主要（不是那么主要）库和框架之间进行持续集成。
- 嵌入Scala编译器的东西使版本脆弱性问题消失了
你可以做什么：
- 关于该问题的博客，并提高人们对版本易损性问题及其对您的影响的意识
- 下次您使用TypeSafe时，“您要付给我们什么钱？” 致电，请告诉他们，充满活力的Scala生态系统对于广泛采用至关重要，而版本脆弱性问题则对内部开发工作和生态系统增长均产生重大影响。 为了使您的公司考虑从TypeSafe购买任何商品，您需要在内部广泛采用Scala，这是因为降低了使用Scala的交易成本，其中包括消除了Scala开源部分中的版本易损性问题。
我今天为什么写这篇文章？ 在上周，Lift列表和Lift提交者列表中出现了很多版本易碎性问题。 我想这是一个不平凡的痛苦，而不是“随波逐流”，我想我会写它，让人们知道这是痛苦，而且这种痛苦可能会消失。
参考： Scala的版本脆弱性使我们的JCG合作伙伴 David Pollak在Good Stuff博客上几乎无法提出Enterprise的论点 。
相关文章 ：
翻译自: https://www.javacodegeeks.com/2011/12/scalas-version-fragility-make.html
2574
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
