Java平臺發展趨勢展望(2)

Java平臺發展趨勢展望(2)

屬性

很可以還有一些針對屬性訪問的語法糖。一個建議是使用 -> 作為調用 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 再一次束之高閣。下一年的這個時候我們就會知道。