Java平臺(tái)發(fā)展趨勢(shì)展望(2)

Java平臺(tái)發(fā)展趨勢(shì)展望(2)

屬性

很可以還有一些針對(duì)屬性訪問的語法糖。一個(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ì)自動(dòng)地分派到相應(yīng)方法中。這樣做所使用的語法更少，也更加靈活。

隨機(jī)精度算法

非操作符重載

值得一提的是，對(duì)標(biāo)準(zhǔn)數(shù)學(xué)符號(hào)的重用不同于 操作符重載，至少不是在 C++ 中引起問題的那種重載。加號(hào)和其他操作符在任何程序中都具有明確的意義。無論在哪一個(gè)程序中，它們的意義都不會(huì)有所更改。對(duì)于相似的操作重用相同的語法讓代碼更易于閱讀。若重新定義語法，使之在不同的程序中有不同的意義，代碼就會(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)建議似乎無關(guān)緊要，但它可能會(huì)導(dǎo)致過度使用這些類，進(jìn)而導(dǎo)致尚不成熟的代碼中性能降低。

將 JAM 從 JAR 中分離出來

Java 7 會(huì)撫平 Java 開發(fā)人員長久以來積聚的憤怒：各種各樣的類加載器和相關(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ǔ)庫，其中要能提供多個(gè)不同的 JAM 的不同版本，應(yīng)用程序能夠從中挑選所需。如果 JMS 適用，jre/lib/ext 將會(huì)成為過去時(shí)。

包訪問

我也希望 Java 7 能夠稍微放松一下訪問限制。子包也許能夠看到上層包里的包保護(hù)字段和類方法。也就是說，子包也許能夠看到上層包里明確聲明友好性的包保護(hù)成員。不論用哪種方式，將應(yīng)用程序分割成多個(gè)包都會(huì)變得簡單的多，也會(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ì)其無比崇尚的真正的異步輸入/輸出文件系統(tǒng)這個(gè)相對(duì)不重要的問題上花費(fèi)過多時(shí)間，從而讓該 API 再一次束之高閣。下一年的這個(gè)時(shí)候我們就會(huì)知道。