期待 Java 7


Dolphin 不會在 2007 年發布。2008 年是更為現實的目標。那就是說，工作尚在進行中，它的一些功能也許會作為早期的標準擴展或至少作為 beta 登場。

遺憾的是，為一門語言添加功能遠比刪除功能要簡單得多。幾乎不可避免地，隨著時間的推移，語言不是朝著簡單的方向發展，而是越來越復雜，越來越讓人困惑。即使是那些單獨看起來很好的功能，在彼此疊加后也會出現問題。

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

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

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

列表

最有可能的是使用數組語法來實現集合訪問。例如，不再采用下面這樣的代碼：

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];

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

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


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

真正能夠影響開發人員生產力的特性功能應該是用于管理表、樹和映射表的內置原語，比如在使用 XML 和 SQL 時遇到的那些。JavaScript 下的 E4X 項目和 Microsoft 的 Cω 和 Linq 項目是實現這一想法的先驅，但可悲的是，Java 平臺似乎錯過了這個機會。如果有人想要通過編譯器來玩一個潛在的救場的游戲，這里是一個不容錯過的好地方。

屬性

很可以還有一些針對屬性訪問的語法糖。一個建議是使用 -> 作為調用 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;

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

將來，您有可能必須將 Point 類中的相關字段顯式地標識為屬性，如：

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

我個人對此并未產生什么深刻的印象。我寧愿 Java 平臺采納一項更為激進的方法，讓我們可以真正地使用公共字段。但，如果將 getter 或 setter 定義為與字段相同的名稱，然后讀寫字段就會相應地自動分派到方法中。這樣做使用的語法更少，也更加靈活。

隨機精度算法

非操作符重載

值得一提的是，對標準數學符號的重用不同于 操作符重載，至少不是在 C++ 中引起問題的那種重載。加號和其他操作符在任何程序中都具有明確的意義。無論在哪一個程序中，它們的意義都不會有所更改。對于相似的操作重用相同的語法讓代碼更易于閱讀。若重新定義語法，使之在不同的程序中有不同的意義，代碼就會較難理解。



另一項將方法替換為操作符的建議致力于 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;
};

寫成這樣會更清晰：

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;
};

這項建議似乎并未無關緊要，但它可能會導致過度使用這些類，進而導致尚不成熟的代碼中性能降級。

將 JAM 從 JAR 中分離出來

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

包訪問

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

文件系統訪問

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

實驗

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