十大理由證明Java正在老去
51CTO推薦：7月編程語(yǔ)言排行榜 Java，正在老去的王者
在我的職業(yè)生涯中，我已經(jīng)編寫了無(wú)數(shù)的Java代碼;而且，我仍然認(rèn)為Java一門偉大的(程序)語(yǔ)言。相對(duì)于C++和Smalltack，Java已經(jīng)有了很大的改進(jìn);但現(xiàn)在，即使是Java，也已經(jīng)開(kāi)始感覺(jué)到了其15年的積重。
事實(shí)上，在我的經(jīng)歷中，我總是不得不面對(duì)Java的設(shè)計(jì)和規(guī)范上的一些錯(cuò)誤、缺陷和不足，這些東西，讓我的Java程序員生活少有樂(lè)趣可言?，F(xiàn)在全世界的Java程序員有數(shù)百萬(wàn)之眾，Java寫就的代碼更達(dá)數(shù)億行，要是我說(shuō)Java在不久的將來(lái)死去，這還有些遠(yuǎn)。不管怎樣，隨著一些兼容JVM的語(yǔ)言出現(xiàn)(我最鐘意Scala)后，這些問(wèn)題變得越發(fā)不能容忍了，我開(kāi)始想，Java老了(但并不脫離JVM)。具體說(shuō)來(lái)，我認(rèn)為Java語(yǔ)言的10大問(wèn)題是：
1、缺少閉包(closure)：我想這個(gè)不需要解釋了。函數(shù)式編程已經(jīng)存在幾十年了，但最近幾年，它們獲得了越來(lái)越多的關(guān)注，最主要的原因，是它可以自然地編寫并行程序。我部分的同意Joshua Bloch強(qiáng)調(diào)在Java中引入閉包的問(wèn)題需要再想一想(BGGA提議的方式真的很糟)，至少閉包的缺失，使得在Java中做任何真正的函數(shù)式編程都是不可能的。
2、缺少一等函數(shù)：這個(gè)問(wèn)題與前一個(gè)有些關(guān)聯(lián)，但我認(rèn)為它更糟糕。在Java里，要達(dá)到類似效果的唯一方式，是使用著名的、丑陋悲慘的單方法匿名內(nèi)部類，但這看上去的確是一個(gè)拙劣的方法。甚至在C#中，也通過(guò)代理機(jī)制，提供了一個(gè)更好的實(shí)現(xiàn)。
3、原生類型(Primitive types)：如果在Java中一切皆對(duì)象，那是多么***啊，但他們偏偏不這樣設(shè)計(jì)。因而，這一點(diǎn)導(dǎo)致了一些問(wèn)題，比如，不能把一個(gè)int放到集合(Collection)里，這個(gè)在Java5中通過(guò)自動(dòng)裝箱特性得到了解決(下面會(huì)提到)。它也造成了傳值與傳引用上的困擾，原生類型數(shù)據(jù)是通過(guò)值傳給方法的(復(fù)制一份拷貝，然后傳給函數(shù))，而真正的對(duì)象是通過(guò)傳遞(譯注：其實(shí)是復(fù)制對(duì)象地址再傳遞，因此應(yīng)該也是傳值方式，只是由于函數(shù)內(nèi)部可通過(guò)這個(gè)對(duì)象地址訪問(wèn)對(duì)象，因此效果上類似傳引用)。
4、自動(dòng)裝箱(Autoboxing)和自動(dòng)拆箱(autounboxing)：這個(gè)特性是為了解決因原生類型的存在所導(dǎo)致的問(wèn)題，在Java5引入的。它允許靜默地轉(zhuǎn)換原生類型到相應(yīng)的對(duì)象，但這常常導(dǎo)致其它的問(wèn)題。比如Integer可以為null，但int不能，因此這時(shí)JVM只能拋出一個(gè)難以調(diào)試的空指針異常(NullPointerException)。此外，它還可能導(dǎo)致其它奇怪的行為，就像下面的例子，我們就很難理解，變量test為什么是false：
- Intger a = new Integer(1024);
- Intger b = new Integer(1024);
- boolean test = a < b || a == b || a > b;
5、缺少范型具類化：范型是Java5引入的一個(gè)很酷的特征，但是為了保持與舊版本Java的兼容性，導(dǎo)致缺失某些重要的特性，尤其是不能在運(yùn)行時(shí)反省范型的類型。例如，你有一個(gè)方法，接受List參數(shù)，如果傳進(jìn)來(lái)一個(gè)List，你卻不能知道運(yùn)行里該范型的確切類型。同理，你也不能創(chuàng)建范型數(shù)組。這意味著，盡管下面的代碼看起來(lái)很自然，但卻不編譯不了：
List[] listsOfStrings = new List[3];
6、不可避免的范型警告：你有發(fā)現(xiàn)過(guò)自己陷入不可能去掉的關(guān)于范型的警告么?如果你像我一樣大量使用范型，我打賭你碰到過(guò)。事實(shí)上，是這個(gè)問(wèn)題的規(guī)?；Y狀，讓他們認(rèn)為需要引入一個(gè)特定的注解 (@SuppressWarnings("unchecked")) 來(lái)處理這種情況，我覺(jué)得，范型應(yīng)該可能被設(shè)計(jì)的更好。
7、不能傳void給方法調(diào)用：我得承認(rèn)，這種給方法傳遞void的需求，乍一看有些怪異。我喜歡DSL，當(dāng)我實(shí)現(xiàn)自己的DSL庫(kù)(lambdaj)的一個(gè)特定特性時(shí)，我不得不需要一個(gè)方法聲明成這樣的簽名：void doSomething(Object parameter)，這里為這個(gè)方法傳進(jìn)來(lái)的參數(shù)parameter，是另一個(gè)方法調(diào)用的結(jié)果，它唯一的目的，是注冊(cè)調(diào)用(的對(duì)象)自身，以可以在以后執(zhí)行它。讓我吃驚的是，即使println方法返回void，看上去也并沒(méi)有一個(gè)好理由，不允許我把代碼寫成這樣，：
doSomething(System.out.println("test"));
8、沒(méi)有原生的代理機(jī)制：代理是一種非常有效和應(yīng)用廣泛的模式，但Java提供的代理機(jī)制，只針對(duì)接口，而不是具體類。這是為什么象cblib這樣提供這種機(jī)制的庫(kù)，被如此多的主流框架，如Spring和Hibernate，采用的原因。此外，由于cglib通過(guò)運(yùn)行時(shí)創(chuàng)建被代理類的子類來(lái)實(shí)現(xiàn)的，因此這些種方式有一個(gè)眾所周知的限制——不能代理final類，比如String。
9、差勁的Switch...case語(yǔ)句：Java規(guī)定，switch...case只能選擇int和enum(Java5開(kāi)始)。這一點(diǎn)如果跟更現(xiàn)代的語(yǔ)言如Scala相比，看起來(lái)簡(jiǎn)直太弱了。
10、受檢查異常(Checked exception)：類似原生類型，受檢查異常也已經(jīng)成為Java的一個(gè)罪孽之源。它迫使程序員必須做下面兩件極其糟糕討厭的事情中的一個(gè)：讓你的代碼里充斥大量的、糟糕難讀的、容易出錯(cuò)的try...catch語(yǔ)句，而這樣做的***意義，只是將捕獲的異常，包裝成運(yùn)行時(shí)異常，然后再重新拋出;或者是讓大量的拋出聲明子句污染你的API，讓接口缺少靈活性和可擴(kuò)展性。
真正的問(wèn)題是，這里我提到的這幾大主要問(wèn)題，唯一的解決辦法，是要做一個(gè)痛苦的決擇，定義一套新的語(yǔ)言規(guī)范，放下當(dāng)前版本的向后兼容性。我猜他們永遠(yuǎn)也不會(huì)這么做，雖然我相信，如果編寫一個(gè)能夠自動(dòng)轉(zhuǎn)換舊Java源碼的程序，讓它們與假設(shè)的新版本兼容，并不是很困難。***，這就是我決定開(kāi)始尋找一個(gè)更好的JVM兼容語(yǔ)言的原因。
【編輯推薦】
