Scala为了在JVM上运行做出了哪些妥协？

Question

Scala是一门很棒的语言，但如果它有自己的运行时环境，它将如何改进呢？
也就是说，由于选择JVM，做了哪些设计选择？

- Łukasz Lew

Answer 1

我知道的最重要的两个折衷方案是：

• 类型擦除（“反射类型”）：它必须管理清单以绕过Java编译（独立于JVM，出于向后兼容性的原因）。
• 基本类型的集合：例如：数组

  Scala 2.8中处理数组的新方案。该方案依赖于隐式转换和清单来集成数组，而不是装箱/拆箱和其他编译器魔术。

当涉及到管理具有边界的泛型类型时，这些是两个主要的JVM限制：Java JVM不保留在泛型对象中使用的确切类型，并且它具有“基本”类型。

---

但你也可以考虑：

• 尾调用优化JVM尚未完全支持, 即使很难实现（不过Scala 2.8引入了@tailrec注释）
• UAP（通用访问原则）需要模拟（Java不支持），并且将很快完成Value Holder (@proxy)的支持
• 所有混合机制也需要进行模拟
• 更一般地，Scala引入的大量静态类型需要（对于大多数类型）在Java中生成：

为了尽可能涵盖更多可能性，Scala提供了以下类型： 常规类类型， 值类类型， 非空类型， Monad类型， Trait类型， 单例对象类型（过程模块，实用程序类等）， 复合类型， 函数类型， Case类， 路径相关类型， 匿名类型， 自类型， 类型别名， 泛型类型， 协变泛型类型， 逆变泛型类型， 有界泛型类型， 抽象类型， 存在类型， 隐式类型， 增强类型， 视图边界类型， 以及结构类型，当其他所有方法都失败时允许一种鸭子类型。

- VonC

---

自己注意：类型列表在 https://dev59.com/JXA75IYBdhLWcg3wxsJn#3113741 中详细列出（带有链接）。 - VonC

Answer 2

本文是与Scala创始人Martin Odersky的讨论，包括为了与Java兼容而做出的妥协。本文提到：

1. 静态方法重载
2. 同时拥有特质和类
3. 包含null指针。

- Ben Lings

Answer 3

这不是运行时的问题，而是一种文化遗留：普遍相等、哈希和toString。

更紧密地与虚拟机相关：默认情况下是严格评估、不纯函数和异常。

- retronym

---

+1 用于通用相等性和哈希。通用的 toString 有什么问题吗？ - missingfaktor

1. 不小心向用户显示 Object#toString 很容易发生。
2. Collection[A]#toString 在显示类型为 A 的元素方面缺乏灵活性。请参考 scalaz.Show 以获取替代方案。

- retronym