期待 Java 7


Dolphin 不會(huì)在 2007 年發(fā)布。2008 年是更為現(xiàn)實(shí)的目標(biāo)。那就是說，工作尚在進(jìn)行中，它的一些功能也許會(huì)作為早期的標(biāo)準(zhǔn)擴(kuò)展或至少作為 beta 登場(chǎng)。

遺憾的是，為一門語(yǔ)言添加功能遠(yuǎn)比刪除功能要簡(jiǎn)單得多。幾乎不可避免地，隨著時(shí)間的推移，語(yǔ)言不是朝著簡(jiǎn)單的方向發(fā)展，而是越來越復(fù)雜，越來越讓人困惑。即使是那些單獨(dú)看起來很好的功能，在彼此疊加后也會(huì)出現(xiàn)問題。

令人遺憾，Java 社區(qū)沒有接受這個(gè)教訓(xùn)，盡管這種失敗并無(wú)特殊性。但總有一些太酷又太讓人激動(dòng)的新語(yǔ)法令語(yǔ)言設(shè)計(jì)者難以抗拒 ?? 即便這樣的新語(yǔ)法不能解決任何實(shí)際問題。于是對(duì) Java 7 的新語(yǔ)言功能就有了巨大的要求，包括閉包、多繼承和操作符重載。

我猜想在這一年結(jié)束前，會(huì)在 Java 7 beta 中看到閉包，也許還能看到操作符重載（有五成的把握），但不會(huì)出現(xiàn)多繼承。Java 中有太多東西是基于單個(gè)根的繼承層次。沒有可行的方式改進(jìn)多繼承，使之適應(yīng)這門語(yǔ)言。

目前有許多語(yǔ)法糖方面的提議，有一些有意義，有一些沒有。許多提議都專注于將像 getFoo() 這樣的方法替換為像 -> 這樣的操作符。

列表

最有可能的是使用數(shù)組語(yǔ)法來實(shí)現(xiàn)集合訪問。例如，不再采用下面這樣的代碼：

List content = new LinkedList(10);
content.add(0, "Fred");
content.add(1, "Barney");
String name = content.get(0);

而是編寫如下代碼：

List content = new LinkedList(10);
content[0] = "Fred";
content[1] = "Barney";
String name = content[0];

另一種可能性是：允許為列表使用數(shù)組初始化程序語(yǔ)法。例如：

LinkedList content = {"Fred", "Barney", "Wilma", "Betty"}


這兩項(xiàng)提議都可以在不改變虛擬機(jī)（VM）的前提下由編譯器稍顯神通即可實(shí)現(xiàn)，這是任何修訂過的語(yǔ)法的一項(xiàng)重要特征。這兩項(xiàng)提議都不能使任何現(xiàn)有的源代碼失效或重定義現(xiàn)有的源代碼，對(duì)于新語(yǔ)法來說，這是一個(gè)更為重要的問題。

真正能夠影響開發(fā)人員生產(chǎn)力的特性功能應(yīng)該是用于管理表、樹和映射表的內(nèi)置原語(yǔ)，比如在使用 XML 和 SQL 時(shí)遇到的那些。JavaScript 下的 E4X 項(xiàng)目和 Microsoft 的 Cω 和 Linq 項(xiàng)目是實(shí)現(xiàn)這一想法的先驅(qū)，但可悲的是，Java 平臺(tái)似乎錯(cuò)過了這個(gè)機(jī)會(huì)。如果有人想要通過編譯器來玩一個(gè)潛在的救場(chǎng)的游戲，這里是一個(gè)不容錯(cuò)過的好地方。

屬性

很可以還有一些針對(duì)屬性訪問的語(yǔ)法糖。一個(gè)建議是使用 -> 作為調(diào)用 getFoo 和 setFoo 的縮寫。例如，不再使用如下代碼：

Point p = new Point();
p.setX(56);
p.setY(87);
int z = p.getX();

而是使用如下代碼：

Point p = new Point();
p->X = 56;
p->Y = 87;
int z = p->X;

也有人建議用另外一些符號(hào)來代替 ->，包括 . 和 #。

將來，您有可能必須將 Point 類中的相關(guān)字段顯式地標(biāo)識(shí)為屬性，如：

public class Point {
public int property x;
public int property y;
}

我個(gè)人對(duì)此并未產(chǎn)生什么深刻的印象。我寧愿 Java 平臺(tái)采納一項(xiàng)更為激進(jìn)的方法，讓我們可以真正地使用公共字段。但，如果將 getter 或 setter 定義為與字段相同的名稱，然后讀寫字段就會(huì)相應(yīng)地自動(dòng)分派到方法中。這樣做使用的語(yǔ)法更少，也更加靈活。

隨機(jī)精度算法

非操作符重載

值得一提的是，對(duì)標(biāo)準(zhǔn)數(shù)學(xué)符號(hào)的重用不同于 操作符重載，至少不是在 C++ 中引起問題的那種重載。加號(hào)和其他操作符在任何程序中都具有明確的意義。無(wú)論在哪一個(gè)程序中，它們的意義都不會(huì)有所更改。對(duì)于相似的操作重用相同的語(yǔ)法讓代碼更易于閱讀。若重新定義語(yǔ)法，使之在不同的程序中有不同的意義，代碼就會(huì)較難理解。



另一項(xiàng)將方法替換為操作符的建議致力于 BigDecimal 和 BigInteger。例如，目前您不得不像這樣編寫不限精度的算法：

BigInteger low = BigInteger.ONE;
BigInteger high = BigInteger.ONE;
for (int i = 0; i < 500; i++) {
System.out.print(low);
BigInteger temp = high;
high = high.add(low);
low = temp;
};

寫成這樣會(huì)更清晰：

BigInteger low = 1;
BigInteger high = 1;
for (int i = 0; i < 500; i++) {
System.out.print(low);
BigInteger temp = high;
high = high + low;
low = temp;
};

這項(xiàng)建議似乎并未無(wú)關(guān)緊要，但它可能會(huì)導(dǎo)致過度使用這些類，進(jìn)而導(dǎo)致尚不成熟的代碼中性能降級(jí)。

將 JAM 從 JAR 中分離出來

Java 7 會(huì)撫平 Java 開發(fā)人員長(zhǎng)久以來積聚的憤怒：各種各樣的類加載器和相關(guān)的 classpath。Sun 公司在 Java Module System 這個(gè)問題上經(jīng)受了又一次打擊。數(shù)據(jù)將存儲(chǔ)到 .jam 文件，而不是 .jar 文件中。這是一種 “superjar”，它包含了所有的代碼和元數(shù)據(jù)。最重要的是，Java Module System 將首次支持版本，所以可以說一個(gè)程序需要 Xerces 2.7.1 而不是 2.6。它也允許指定依賴項(xiàng)；例如，可以說一個(gè) JAM 程序需要 JDOM。它也要允許在加載一個(gè)模塊時(shí)不必加載全部模塊。最終，它要支持一個(gè)集中式的存儲(chǔ)庫(kù)，其中要能提供多個(gè)不同的 JAM 的不同版本，應(yīng)用程序能夠從中挑選所需。如果 JMS 適用， jre/lib/ext 將會(huì)成為過去時(shí)。

包訪問

我也希望 Java 7 能夠稍微放松一下訪問限制。子包也許能夠看到上層包里的包保護(hù)字段和類方法。也就是說，子包也許能夠看到上層包里明確聲明友好性的包保護(hù)成員。不論用哪種方式，將應(yīng)用程序分割成多個(gè)包都會(huì)變得簡(jiǎn)單的多，也會(huì)顯著地改善可測(cè)試性。只要子包中含有單元測(cè)試，就不必使用公共方法去進(jìn)行測(cè)試。

文件系統(tǒng)訪問

自從 1995 年開始，文件系統(tǒng)訪問就成為 Java 平臺(tái)的一個(gè)主要問題。十多年后，還是沒有可信賴的跨平臺(tái)方式來執(zhí)行如復(fù)制或移動(dòng)文件這類基本操作。處理這個(gè)問題是過去至少三個(gè)版本的 JDK（1.4、1.5 和 1.6）的公開問題。遺憾的是，為了迎合不怎么普遍卻更具誘惑的操作，如內(nèi)存映射 I/O，有些乏味但卻很必要的 API 被擱到了一邊。JSR 203 可能會(huì)最終解決這個(gè)問題，給我們一個(gè)可行的、跨平臺(tái)文件系統(tǒng) API。工作組也許會(huì)再一次對(duì)其無(wú)比崇尚的文件系統(tǒng)真實(shí)異步這個(gè)相對(duì)不重要的問題花費(fèi)過多時(shí)間，從而讓該 API 再一次束之高閣。下一年的這個(gè)時(shí)候我們就會(huì)知道。

實(shí)驗(yàn)

無(wú)論做出什么樣的改變，如果它們首先是在開源社區(qū)里實(shí)現(xiàn)，那么都是令人愉快的，所以我們只要看一下真正的區(qū)別有多大或多小。為此，Sun 公司的 Peter Ahè 開始了 java.net 上的 Kitchen Sink Project。目標(biāo)是要分別地分派和指定 javac 編譯器，來測(cè)試像這樣的許多不同想法。在博客里寫寫這些可愛的功能是一回事；但真正制造運(yùn)行的代碼則全然是另一回事。