Scala团队宣布2.12版本将只支持Java 8及更高版本。InfoQ对Adriaan Moors和Jason Zaugg进行了采访，探讨这一改变的原因和挑战。尽管Scala已具备类似Java 8的功能，但语义差异和向JDK 8的迁移可能带来问题。团队认为这既是威胁也是机会，可能会扩大Scala的用户基础。对于Scala 3的版本编号，存在一定的困惑。
正如最近在Scala路线图中所宣布的那样，Scala语言将仅在Java 8以及更高版本的Scala 2.12及更高版本上运行。 InfoQ采访了Adriaan Moors（Typesafe的Scala技术负责人）和Jason Zaugg（Typesafe的工程师），以了解有关此更改的更多信息以及Scala将如何利用Java 8的lambdas实现。
InfoQ：做出改变的最大推动力是什么？
Adriaan：以Java平台为目标对Scala的成功和Swift采用起了作用。 我们渴望与该平台一起发展，以享受对该平台及其生态系统所做的改进。 对lambda的本机支持使Java 8 VM成为Scala的更好宿主。
InfoQ：您认为进行更改时最大的挑战是什么？
Adriaan：迁移到Java 8对我们来说是自然而然的发展。 例如，Scala 2.11已经具有实验性功能，可以在Java 6上尽可能地模拟Java 8样式的功能。
函数的主体被提升为封闭类的私有方法，而实例化以在运行时表示该函数的匿名类由仅调用提升方法的方法组成。 通过使用Java 8，我们不再需要在编译时生成此匿名类，而是在运行时使用LambdaMetaFactory。 同样，2.11类型检查器支持根据Scala函数文字（在-Xexperimental下运行时）合成Single Abstract Method类。
这些是挑战的技术方面的亮点。 正如您所期望的那样，随着平台的改变，社交方面是一个非常重要的因素。 关于2.12的所有内容都是围绕促进升级而计划的，我们希望社区积极进行。 快速采用Scala 2.12取决于核心库，测试框架，IDE支持和其他工具的可用性。 也就是说，我们意识到并不是每个人都可以立即升级到Java 8。 为此，我们计划在语言和库中限制2.11和2.12之间的差异。 我们希望使开放源代码作者交叉编译为这两个版本变得非常简单，这是使2.11成为更长时期可行目标的重要组成部分。 2.12路线图详细说明了我们打算如何执行此策略。
InfoQ：从最初的博客文章看来，这是一个相当大的变化，涉及许多 Scala的子系统。 您认为需要完成多大的团队？
Adriaan：很难在“ Scala团队”的人数上增加数字。 与往常一样，大部分工作将由社区来完成。 一些Typesafe工程师正在研究Scala的Java 8支持：特别是，Jason Zaugg正在研究Java 8样式的lambda，而Lukas Rytz正在继续Miguel Garcia在基于ASM的新后端和优化器上开始的工作。 本质上的全部努力贯穿了整个公司：Akka＆Play具有出色的Java 8 API，我们将继续完善它们，Scala IDE和sbt已经支持Java 8，我们所有其他工具也是如此。
InfoQ：一段时间以来，Scala具有与Java 8基本相同的功能。 Scala与Java 8附带的东西之间在语义上 是否 存在差异，您 认为在采用JDK 8作为后端时会引起问题吗？
杰森（Jason）：在一些极端的情况下，JDK8 LambdaMetaFactory的语义对我们来说不是开箱即用的。 例如，它不知道如何使用BoxedUnit将值类装箱/拆箱，或如何将void返回方法句柄桥接到FunctionN :: apply的通用返回类型。 但是我们有很多选择可以适应这些限制：在某些情况下，我们可以选择遵循当前的匿名类编码，或者可以发出执行必要装箱的访问器方法。 在基元上正确地发布专用的功能版本也需要一些仔细的工作。 但是，我们已经为这些挑战制定了解决方案的原型，并且非常有信心没有表演障碍。
我们还计划利用默认方法来编译特征（Scala的轻量级多重继承形式）。 这种编码将受到更多限制：除其他限制外，它不适用于使用重写类中方法的方法的特征，也不支持字段。 根本没有为这个应用程序设计默认方法，但是默认方法是设计二进制兼容性的重要资产。 将来的JDK版本可能会在此处提供更强大的工具。 布莱恩·格茨（Brian Goetz）最近起草的关于类动力学的提议对于Scala来说是极有希望的。
InfoQ：对JDK 8中的lambdas子系统的总体设计还有其他意见吗？
Jason： lambda实现的JDK方面似乎构想并执行得很好。 关键的设计见解集中于nvokedynamic的使用（推迟编码的细节）。 反过来，这建立在对调用动力学本身的前瞻性规范的基础上，该规范经受了一个出色的API的考验：已经以API作者无法预见的方式成功使用了它！ 也就是说，通过Java语言公开lambda的方式对Scala进行了一系列折衷。 最显着的区别是使用功能接口，而不是各种Arities的功能的一组规范的通用类型。 这本身并不是一件坏事：我们也在扩展我们的功能以支持功能接口。 但是，手动专用功能接口的选择似乎是临时的，使编写通用代码更加困难。
InfoQ：Java 8显然带来了使用一些基本功能惯用法（映射， 过滤器等）的能力。 您认为这对Scala是威胁还是机遇？ 是要带走 原本会使用Scala的开发人员，还是增加 可能成为Scala用户 的 开发人员 规模 ？
Adriaan：我绝对相信这对Scala来说是一个绝佳的机会。 函数式编程不仅涉及函数文字的轻量级语法，而且涉及多态方法调用的更多类型推断。 这仅仅是开始。 对我来说，它是关于通过构成适当大小的抽象来构建和理解程序的。 Scala提供了整个范围：从编写和定义单方法抽象（函数）到多个连贯的
类（特征）。 对我来说，（静态类型的）FP语言：
1）专注于组成小的，易于理解的功能单元。 函数很容易理解，因为它们仅取决于参数。 函数的类型和用于组合它们的组合器捕获程序的高级结构。 类型有点像高科技管道：对于正确引导数据，同时适应结构变化而不会造成阻碍，必不可少。 仅当管道被语言隐藏时，这才是正确的。 Scala强大的本地类型推断对于轻松使用FP库至关重要，因为它们倾向于大量使用泛型。 可以通过IDE支持来增强Java 8的有限类型推断，但这导致了维护由IDE生成的关于类型的样板的古老问题。
2）有一个类型系统，可让图书馆设计人员简洁地表达这些安全的高阶抽象。 Scala长期以来一直支持高阶参数多态性（“更高种类的类型”或“类型构造函数多态性”）以及即席多态性。 Java的泛型严格是一阶的，而重载是即席多态性的一种极其有限的形式，它造成的痛苦大于收益。
3）鼓励不变性。 不可变的代码通常更容易理解。 它还具有明显的优势，可以扩展您的应用程序（使用计算机中或整个数据中心的所有内核）并划分故障（当然使用Akka）。 具体而言，变异通常导致难以诊断代码不同部分之间的纠缠。 Scala在这里也是实用的：val和var故意只是一个字母不同（尽管Scala IDE用红色突出显示了对可变变量的引用）。
4）通过根据此数据的模式匹配定义功能（并确保涵盖所有情况），偏向于具有不断发展的操作的固定数据模型； Scala将此与OOP进行了补充和深度集成，OOP的重点是不断发展的数据模型，具有恒定的功能（请参阅Visitor模式）。
InfoQ：最后，我们的一位编辑对2.12是主要 版本 感到有些困惑 。 有计划将Scala 3编号更改吗？
Adriaan：我们将需要用户采取行动的两种升级区分开来：仅需要重新编译的升级（它们保留源兼容性但不支持二进制兼容性），以及涉及更多的升级，需要更改源代码。 我们为后一种升级保留了版本（时代）中最重要的部分，即“稀有”（假设十年一次）。 我们每18个月左右发布一个新的主要版本，这会影响版本号的中间部分。 为了确保顺利升级，只要解决了弃用警告，就可以在相邻的主要Scala版本上编译相同的代码库，而无需进行修改。 弃用是我们流程的关键部分：我们会尽最大努力（保守地）平衡稳定性和演进，并且不会轻易破坏您的代码，但是我们相信每个人都将从健康的创新步伐中受益。
最后，次要版本的Scala是无法区别的直接替换，它们应该是向前和向后二进制兼容的。 它们的节奏是可变的：在发布周期的早期，它们可能每隔一个月发生一次，随着我们的开发重点转移到下一个主要版本，它会放缓到每季度发布一次。
如路线图中所述，我们计划在2.11和2.12主要版本之间进行交叉构建至少要像在2.10和2.11中进行交叉构建一样容易。 当我们在Scala 3中破坏源代码兼容性时，我们会非常保守地这样做，并且出于诸如简化语言和加快编译器之类的充分理由。
当从Scala xyz转到（x + 1）.yz时，您可能必须更改源代码或使用工具来为您执行此操作。 从xyz升级到x。（y + 1）.z时，您只需要在处理旧版本中的弃用警告的情况下重新编译，因为弃用的成员可能已在新版本中删除。 最后，Scala xya和xyb应该可以互换使用。
关于被访者
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
