更好的Java受到的约束

　　Artima：您说您那时候感到很沮丧，遇到一些约束，需要向后兼容Java。您能否提供一些遇到约束的具体的例子?

　　Martin Odersky：在泛型设计中，有很多非常强硬的约束。其中最强、最难以应付的是，它必须充分地向后兼容非泛型Java。Collections类库只停留在1.2版本，而且仅仅因为泛型的出现，Sun不准备推出全新的Collections类库。因此，只能完全透明工作。(51CTO编者：有关Collections类库的更多内容，可参考这篇基于JDK 5.0一些collection类的使用总结，以及《Java语言的科学与艺术》一书中的Collection层次结构章节。)

　　这就是为什么总会存在一些相当难看的东西。你总是不得不使用具有泛型类型的非泛型类型，即所谓的raw(原始)类型。还有，你不能改变数列行为，否则就会有未经检查的警告。最重要的是，你不能利用数组做你想做的很多事情，比如生成一个具有类型参数的数组。后来在Scala，我们知道了实际上能如何实现这些事情，但是这可能仅仅是因为我们给Scala设置的条件是协变数组。

　　Artima：您能否就Java的协变数组详细说明一下该问题?

　　Martin Odersky：当Java刚出现时，Bill Joy和James Gosling以及其他Java组成员都认为，Java应该有泛型，只是他们没有足够的时间做出详细设计。所以由于Java中没有泛型，至少最初阶段没有，他们就认为，数组不得不是协变的。例如，这意味着一个字符串(String)数组是一个对象(Object)数组的子类型。其原因是他们希望能够重写，比如，一个“通用”排序方法，采用了一个对象数组和一个用来排序该数组的比较器，然后让你传送一个字符串数组的参数给它。通常情况下这属于类型不健全。这就是为什么在Java中你会获得一个数组存储例外。这实际上也证明，这种同样的事情引起了对于数组泛型实现的需求。这就是为什么在Java中泛型并不好使。你不能定义一个字符串的列表数组，这是不可能的。你只能被迫使用难看的原始类型，永远都只能是一个列表数组。因此，这有点类似原罪。他们对此做出了非常迅速的回应，认为这是一个快速破解。但随后实际上每一个设计决定都被毁灭了。因此，为了不陷入同样的陷阱，我们不得不中断，并提出现在我们将不向上兼容Java，我们也想做一些不同的事情。

　　编者后记

　　Scala到目前为止还是一个相对小众的语言，在TIOBE每月的排行榜上都在20到30之间浮动，与每月业内知名的Java在流行程度上仍有很大的差距。然而Scala在数年之间已经得到了越来越多开发者的关注，在国外的开发者讨论区中常常会看到有Scala的专区。Scala在现在以及未来的开发界绝对是一个不可忽视的语言。