发新话题
打印

离开Java,寻找更佳语言的10大理由

离开Java,寻找更佳语言的10大理由

别误解,其真实我的职业生涯中,我已经编写了有数的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,你却不能晓得运行里该范型的确切类型。同理,你也不能创建范型数组。这意味着,虽然下面的代码看起来很自然,但却不编译不了:  List[] listsOfStrings = new List[3];
6、不可避免的范型正告:你有发现过自己堕入不可能去掉的关于范型的正告么?假如你像我一样大量使用范型,我打赌你碰到过。理想上,是这个问题的规模化症状,让他们认为需求引入一个特定的注解 (@SuppressWarnings("unchecked")) 来处理这种状况,我觉得,范型应该可能被设计的更好。1
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兼容语言的缘由。
jiyizhen-buy.com颈椎保健枕太空记忆枕 igerl.com歌瑞尔内衣

TOP

发新话题