离开Java，寻找更佳语言的10大理由-CSDN博客

作者：Mario Fusco

译者：liuu

别误解，其实在我的职业生涯中，我已经编写了无数的Java 代码；而且，我仍然认为Java 一门伟大的（程序）语言。相对于C++ 和Smalltack ，Java 已经有了很大的改进；但现在，即使是Java ，也已经开始感觉到了其15 年的积重。

事实上，在我的经历中，我总是不得不面对Java 的设计和规范上的一些错误、缺陷和不足，这些东西，让我的Java 程序员生活少有乐趣可言。现在全世界的Java 程序员有数百万之众，Java 写就的代码更达数亿行，要是我说Java 在不久的将来死去，这还有些远。不管怎样，随着一些兼容JVM 的语言出现（我最钟意Scala ）后，这些问题变得越发不能容忍了，我开始想，是时候慢慢离开Java 了（但并不脱离JVM ）。具体说来，我认为Java 语言的10 大问题是：

1 、缺少闭包（closure ）：我想这个不需要解释了。函数式编程已经存在几十年了，但最近几年，它们获得了越来越多的关注，最主要的原因，是它可以自然地编写并行程序。我部分的同意Joshua Bloch 强调在Java 中引入闭包的问题需要再想一想（BGGA 提议的方式真的很糟），至少闭包的缺失，使得在Java 中做任何真正的函数式编程都是不可能的。

2 、缺少一等函数：这个问题与前一个有些关联，但我认为它更糟糕。在Java 里，要达到类似效果的唯一方式，是使用著名的、丑陋悲惨的单方法匿名内部类，但这看上去的确是一个拙劣的方法。甚至在C# 中，也通过代理机制，提供了一个更好的实现。

3 、原生类型（Primitive types ）：如果在Java 中一切皆对象，那是多么完美啊，但他们偏偏不这样设计。因而，这一点导致了一些问题，比如，不能把一个int 放到集合（Collection ）里，这个在Java5 中通过自动装箱特性得到了解决（下面会提到）。它也造成了传值与传引用上的困扰，原生类型数据是通过值传给方法的（复制一份拷贝，然后传给函数），而真正的对象是通过传递（译注：其实是复制对象地址再传递，因此应该也是传值方式，只是由于函数内部可通过这个对象地址访问对象，因此效果上类似传引用）。

4 、自动装箱（Autoboxing ）和自动拆箱（autounboxing ）：这个特性是为了解决因原生类型的存在所导致的问题，在Java5 引入的。它允许静默地转换原生类型到相应的对象，但这常常导致其它的问题。比如Integer 可以为null ，但int 不能，因此这时JVM 只能抛出一个难以调试的空指针异常（NullPointerException ）。此外，它还可能导致其它奇怪的行为，就像下面的例子，我们就很难理解，变量test 为什么是false ：

Intger a = new Integer(1024);

Intger b = new Integer(1024);

boolean test = a < b || a == b || a > b;

5 、缺少范型具类化：范型是Java5 引入的一个很酷的特征，但是为了保持与旧版本Java 的兼容性，导致缺失某些重要的特性，尤其是不能在运行时反省范型的类型。例如，你有一个方法，接受List<?> 参数，如果传进来一个List<String> ，你却不能知道运行里该范型的确切类型。同理，你也不能创建范型数组。这意味着，尽管下面的代码看起来很自然，但却不编译不了：

List<String>[] listsOfStrings = new List<String>[3];

6 、不可避免的范型警告：你有发现过自己陷入不可能去掉的关于范型的警告么？如果你像我一样大量使用范型，我打赌你碰到过。事实上，是这个问题的规模化症状，让他们认为需要引入一个特定的注解 (@SuppressWarnings("unchecked")) 来处理这种情况，我觉得，范型应该可能被设计的更好。

7 、不能传void 给方法调用：我得承认，这种给方法传递void 的需求，乍一看有些怪异。我喜欢DSL ，当我实现自己的DSL 库（lambdaj ）的一个特定特性时，我不得不需要一个方法声明成这样的签名：void doSomething(Object parameter) ，这里为这个方法传进来的参数parameter ，是另一个方法调用的结果，它唯一的目的，是注册调用（的对象）自身，以可以在以后执行它。让我吃惊的是，即使println 方法返回void ，看上去也并没有一个好理由，不允许我把代码写成这样，：

doSomething(System.out.println("test"));

8 、没有原生的代理机制：代理是一种非常有效和应用广泛的模式，但Java 提供的代理机制，只针对接口，而不是具体类。这是为什么象cblib 这样提供这种机制的库，被如此多的主流框架，如Spring 和Hibernate ，采用的原因。此外，由于cglib 通过运行时创建被代理类的子类来实现的，因此这些种方式有一个众所周知的限制——不能代理final 类，比如String 。

9 、差劲的Switch...case 语句：Java 规定，switch...case 只能选择int 和enum （Java5 开始）。这一点如果跟更现代的语言如Scala 相比，看起来简直太弱了。

10 、受检查异常（Checked exception ）：类似原生类型，受检查异常也已经成为Java 的一个罪孽之源。它迫使程序员必须做下面两件极其糟糕讨厌的事情中的一个：让你的代码里充斥大量的、糟糕难读的、容易出错的try...catch 语句，而这样做的最大意义，只是将捕获的异常，包装成运行时异常，然后再重新抛出；或者是让大量的抛出声明子句污染你的API ，让接口缺少灵活性和可扩展性。

真正的问题是，这里我提到的这几大主要问题，唯一的解决办法，是要做一个痛苦的决择，定义一套新的语言规范，放下当前版本的向后兼容性。我猜他们永远也不会这么做，虽然我相信，如果编写一个能够自动转换旧Java 源码的程序，让它们与假设的新版本兼容，并不是很困难。最后，这就是我决定开始寻找一个更好的JVM 兼容语言的原因。

注：原文见TSS http://www.theserverside.com/news/thread.tss?thread_id=55185 ，感觉作者说的还是有些道理的。