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

屬性

創(chuàng)新互聯(lián)建站是創(chuàng)新、創(chuàng)意、研發(fā)型一體的綜合型網(wǎng)站建設(shè)公司，自成立以來公司不斷探索創(chuàng)新，始終堅持為客戶提供滿意周到的服務(wù)，在本地打下了良好的口碑，在過去的10年時間我們累計服務(wù)了上千家以及全國政企客戶，如主動防護網(wǎng)等企業(yè)單位，完善的項目管理流程，嚴(yán)格把控項目進度與質(zhì)量監(jiān)控加上過硬的技術(shù)實力獲得客戶的一致稱揚。

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

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

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

public class Point {

public int property x;

public int property y;

}

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

隨機精度算法

非操作符重載

值得一提的是，對標(biāo)準(zhǔn)數(shù)學(xué)符號的重用不同于 操作符重載，至少不是在 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;

};

這項建議似乎無關(guān)緊要，但它可能會導(dǎo)致過度使用這些類，進而導(dǎo)致尚不成熟的代碼中性能降低。

將 JAM 從 JAR 中分離出來

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

包訪問

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

文件系統(tǒng)訪問

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