2007 年 2 月 26 日

2007 年將是載入史冊的一年，Sun Microsystems 公司將于這一年在開源許可協(xié)議下發(fā)布 Java 開發(fā)包（JDK），從而放棄了對 Java? 平臺的統(tǒng)馭，將權(quán)力交給了 Java 開發(fā)人員社區(qū)！在本文中，Java 開發(fā)人員 Elliotte Rusty Harold 從各個方面預(yù)測了 Java 平臺的新方向，從腳本到 bug 修復(fù)到新語法。

2006 年又是 Java 平臺繁榮的一年。盡管遭遇了來自 Microsoft（C#）和腳本語言社區(qū)（Ruby）的沖擊，但 Java 語言仍然保持著其世界頭號編程語言的地位。同時，盡管 Java 6 的發(fā)布很值得慶祝，但比起宣布 Java 將在 GNU General Public License 下完全開源這一事件來說，卻不免有些黯然失色。Java 在 2007 年還能保持這種勢頭嗎？讓我們來看一下成敗的可能。

Java 平臺將成為開源平臺

2007 年上半年，Sun 將在一個開源許可協(xié)議下發(fā)布 Java 開發(fā)包（JDK）。解除 JDK 的禁錮對于 Java 開發(fā)人員社區(qū)來說是巨大的一步，它將在今后的十年中推動 Java 平臺的發(fā)展。

JDK 的質(zhì)量將會顯著改善，因?yàn)槌绦騿T們不再僅僅報告 bug 并開始修復(fù)。Java Developer Connection 的 bug 報告將會包括對 JDK 中的問題部分的詳細(xì)分析，并提供修復(fù)的補(bǔ)丁。正如Linus 法則 所陳述的那樣，“只要給予足夠的關(guān)注，任何 bug 都是顯而易見”，即調(diào)試是可并行進(jìn)行的。優(yōu)化也是一樣。開源使兩者得以 并行。

分支項(xiàng)目

遺憾的是，設(shè)計(jì)并不是和調(diào)試、優(yōu)化一樣可以并行完成的。清潔的 API 有時也需要有一只獨(dú)裁的手。但獨(dú)裁者的缺點(diǎn)是：有時他們知道在做什么，有時卻不知道。意圖成為獨(dú)裁者的各方面之間的競爭往往是發(fā)現(xiàn)問題最佳解決方案的惟一方式。

很少有公司能夠負(fù)擔(dān)得起這樣的代價，為一個產(chǎn)品開發(fā)多個獨(dú)立的實(shí)現(xiàn)，以便在多個產(chǎn)品中選定保留一個而摒棄其余的產(chǎn)品，但開源社區(qū)卻在朝這個方向努力。所以，您會在 Java 平臺的各個層次中發(fā)現(xiàn)分支產(chǎn)品：語言、虛擬機(jī)和庫。大多數(shù)的分支產(chǎn)品會失敗，但這沒什么。好主意會脫穎而出。一些分支產(chǎn)品會一直存在下去，一些會重新并入標(biāo)準(zhǔn) JDK 中。明年的這個時候，分支產(chǎn)品與主流產(chǎn)品之間的差異也許不會很明顯，但這個過程會繼續(xù)下去。

Sun 會在幾個月后發(fā)布 Java 7，Dolphin 的一個早期的 beta 版，以此作為開端。Sun 無法發(fā)布更早的 JDK 版本，因?yàn)榇嬖谝恍┲挥性?Dolphin 中才能解決的構(gòu)建問題和許可協(xié)議問題。盡管如此，仍有望看到第三方著手進(jìn)一步細(xì)分 Sun 的版本，來提供 Java 6、Java 5、Java 1.4，甚至更早版本的流行開源實(shí)現(xiàn)。

早期的一些探尋分支產(chǎn)品的人們可能會侵犯 Sun 公司的商標(biāo)，收到 Sun 的律師寄來的討厭的律師信。我們需要一個通用的未注冊為商標(biāo)的名字，讓所有人都能使用。我建議用 “J” —— 我希望沒人用單字母作商標(biāo)。

開源項(xiàng)目從未消亡，只是有些褪色。就像之前的 Blackdown Project、GNU Classpath、Kaffe 和其他開源 JDK 項(xiàng)目一樣，他們的開發(fā)人員都轉(zhuǎn)向其他事情了。如果一個項(xiàng)目至今還沒有達(dá)到 1.0，那么恐怕以后永遠(yuǎn)也達(dá)不到了。

回頁首

期待 Java 7

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

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

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

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

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

列表

最有可能的是使用數(shù)組語法來實(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ù)組初始化程序語法。例如：

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

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

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

屬性

很可以還有一些針對屬性訪問的語法糖。一個建議是使用 -> 作為調(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 平臺采納一項(xiàng)更為激進(jìn)的方法，讓我們可以真正地使用公共字段。然而，如果將 getter 或 setter 定義為與字段相同的名稱，然后讀寫字段就會自動地分派到相應(yīng)方法中。這樣做所使用的語法更少，也更加靈活。

隨機(jī)精度算法

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

另一項(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;
                                    };

寫成這樣會更清晰：

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)緊要，但它可能會導(dǎo)致過度使用這些類，進(jìn)而導(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。它也允許指定依賴項(xiàng)；例如，可以說一個 JAM 程序需要 JDOM。它也要允許在加載一個模塊時不必加載全部模塊。最終，它要支持一個集中式的存儲庫，其中要能提供多個不同的 JAM 的不同版本，應(yīng)用程序能夠從中挑選所需。如果 JMS 適用，jre/lib/ext 將會成為過去時。

包訪問

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

文件系統(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)這個相對不重要的問題上花費(fèi)過多時間，從而讓該 API 再一次束之高閣。下一年的這個時候我們就會知道。

實(shí)驗(yàn)

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

回頁首

客戶機(jī) GUI

盡管許多人還沒注意到，但 Java 平臺真正出現(xiàn)在桌面上到現(xiàn)在已經(jīng)有四五年了。已經(jīng)有幾個優(yōu)質(zhì)的桌面應(yīng)用程序是用 Java 代碼編寫的，包括 RSSOwl、Limewire、Azureus、Eclipse、NetBeans、CyberDuck 等等。這些應(yīng)用程序幾乎用了每一個可用的 GUI 工具包來編寫，包括 Swing、AWT、SWT，甚至是平臺原生的工具包，如 Mac OS X 的 Cocoa。我看不出下一年會有哪個工具包在眾多工具包中勝出，盡管 Swing 在制造一些保留本色的應(yīng)用程序方面似乎比其他工具包表現(xiàn)得更為出色。

用 Swing 進(jìn)行開發(fā)仍是相對挑戰(zhàn)的，但隨著 Swing 應(yīng)用程序框架的到來，這種情況也許會在下一年得到改善。這一框架目前尚在 Java Community Process 中作為 JSR 296 開發(fā)。下面是 JSR 關(guān)于此的描述：

編寫良好的 Swing 應(yīng)用程序試圖為啟動和停止，以及管理資源、行為和會話狀態(tài)的代碼使用相同的核心元素。新應(yīng)用程序從頭開始創(chuàng)建所有這些核心元素。Java SE 不支持構(gòu)造應(yīng)用程序，這常常讓開發(fā)新手們感到有點(diǎn)茫然，特別是在他們打算構(gòu)建一個規(guī)模遠(yuǎn)超于 SE 文檔中提供的例子的應(yīng)用程序時。

通過定義 Swing 應(yīng)用程序的基本結(jié)構(gòu)，這項(xiàng)規(guī)范（最終）會添補(bǔ)該空白。它會定義一小套可擴(kuò)展的類或 “框架”，用于定義相對于大多數(shù)桌面應(yīng)用程序較普遍的基礎(chǔ)設(shè)施。

Swing 應(yīng)用程序框架應(yīng)支持典型應(yīng)用程序中的大多數(shù)東西，允許開發(fā)人員恰在一些自定義的點(diǎn)處插入，如啟動和停止時。在啟動和停止之間，它將處理 windows 的保存和恢復(fù)，以及應(yīng)用程序的其他部分。最后，它將允許開發(fā)人員編寫在 Swing 事件分派線程外運(yùn)行的異步行為。

改善 JavaBeans 以及所有依賴它的東西（包括 Swing）的工作尚在繼續(xù)。JSR 295 正在定義一種將 bean 綁定到一起的標(biāo)準(zhǔn)方式，這樣，對一個 bean 的修改就會自動地反映到其他的 bean。例如，一個 GUI 網(wǎng)格 bean 會在其相關(guān)數(shù)據(jù)庫 bean 改變時自動更新。

最終，JSR 303 正在實(shí)現(xiàn)一門基于 XML 的驗(yàn)證語言，來聲明式地指定任何給定的 bean 將取什么值。int 屬性將必須介于 1 到 10 之間，或者 String 屬性必須包含一個合法的電子郵件地址。如果幸運(yùn)，這一切都將在年底以 beta 形式提供，并將在來年的 Java 7 中按時完成。

回頁首

作為桌面語言的 Java 平臺

一些程序員們選擇用 Java 代碼編寫他們的桌面應(yīng)用程序是因?yàn)樗鼈兤珢圻@門語言，但大多數(shù)程序員則是被多平臺轉(zhuǎn)換這一強(qiáng)烈的渴望所驅(qū)動。對 Java 平臺作為桌面語言的興趣于是就同非 Microsoft 桌面的數(shù)目緊緊地聯(lián)系了起來。讓我們認(rèn)為 Java 編程會在來年出現(xiàn)在三大主流桌面上。

Windows

Swing 在下一年會繼續(xù)對其類似 Windows 的外觀作出小的改進(jìn)，尤其是轉(zhuǎn)換到開源開發(fā)這一部分。結(jié)果，純 Java 程序如 LimeWire 甚至?xí)仍?Windows 下看起來更加具原生感。但開發(fā)原生 Windows 應(yīng)用程序所選擇的語言仍是 C#（還有一些 C 和 C++ 的追隨者），而開發(fā)框架會選用 .NET。Java 代碼不會對 Windows 生態(tài)系統(tǒng)造成任何顯著打擊。

Macintosh

像 Microsoft 一樣，Apple Inc. 也使用了相當(dāng)多被拋棄的 Java 代碼。Apple 公司喜愛 Objective C 和 Cocoa，但最后的結(jié)果是相同的：只用 Mac 的開發(fā)人員會繼續(xù)減少 Java 代碼，而選擇 Apple 偏愛的語言和環(huán)境。

積極的一面是，盡管 Apple 不再在其私有的 API（如 QuickTime 和 Cocoa）中支持 Java 代碼，Apple VM 已經(jīng)比前些年改進(jìn)了不少。Apple 的 Java 6 移植版不久就會發(fā)布。它不會是開源的（不同于 Sun 的 JDK），但開源程序員們還是會著手修補(bǔ)它的 bug。

Linux

GPL 許可協(xié)議將使這成為可能，即將 Java 代碼綁定到最純的開源 Linux 發(fā)行版中，這將使 Java 平臺成為 Linux 開發(fā)中更為吸引人的語言。如果這些在五年前發(fā)生的話：Linux 社區(qū)將不會不得不掙扎于使用 C 語言，而 Mono 也不會成為必要。

已經(jīng)有了針對 Gnome 和 KDE 的 Java 綁定，所以希望這些會在接下來的一年里吸引更多人的關(guān)注。也期望至少有一個即將進(jìn)行的開發(fā) Linux GUI 程序的主要項(xiàng)目使用 Java 語言而不是 C、C++ 或 C#。

回頁首

Ruby 取勝

臃腫的軟件 JavaScript 已經(jīng)和 JDK 6 綁定到了一起。其他語言也許會添加進(jìn) JDK 7。我覺得那樣會有點(diǎn)臃腫。首先，Sun 公司絕不會加入一門語言就停下來。如果它選了 BeanShell，擁護(hù) Groovy 的家伙也會要求加入。如果加入了 Groovy，用 Ruby 的家伙也會堅(jiān)持要加入。如果 Ruby 加入，還能忽略 Python 嗎？標(biāo)準(zhǔn) JDK 已經(jīng)太龐大了。支持多種腳本語言是一回事，但將它們綁定到一起還是同一件事嗎？策略性的改進(jìn)應(yīng)該是支持所有這些語言，但一個也不綁定進(jìn)來。 積極的一面是，Sun 公司正在研究減小初始下載尺寸和減少應(yīng)用程序啟動時間的方法，尤其是 applet 和 Java Web Start 應(yīng)用程序?？赡艿姆椒ㄊ牵瑢⒋罅康念悗旆诺椒?wù)器上或放到速度較慢的后臺線程中，只下載需要的部分。

如果我們只說一門語言，世界將會索然無味。盡管 Java 平臺是開發(fā)成熟應(yīng)用程序的絕佳選擇，但它從來就不適應(yīng)于小程序或宏。Java 6 意識到了這一點(diǎn)，它添加了 javax.script 包實(shí)現(xiàn)，以便和腳本語言（如 BeanShell、Python、Perl、Ruby、ECMAScript 和 Groovy）進(jìn)行互操作，也添加了一項(xiàng) invokedynamic 虛擬機(jī)指令來允許將動態(tài)類型語言直接編譯為 Java VM。

2007 年，我將寶押在 Ruby 上，盡管它并不是我個人的最愛。對于我來說，Python 代碼似乎比 Ruby 代碼更簡潔更易于理解，我認(rèn)為大多數(shù) Java 程序員都會這樣認(rèn)為。然而，Python 出來的不是時候。許多開發(fā)人員不得不在學(xué)習(xí) Python 代碼還是學(xué)習(xí) Java 代碼間作出選擇，而多數(shù)人選擇了 Java 代碼。既然他們終于弄懂了 Java 語法，又打算在工具箱中添加另一門語言，他們想要的是明天的語言，而不是昨天的語言，而那門語言似乎就是 Ruby。更重要的是，Ruby 的 Ruby on Rails 是一個絕對殺手級的應(yīng)用程序。它的簡單性對于多數(shù)覺悟了的 Java 企業(yè)版（Java Enterprise Edition，JEE）開發(fā)人員來說具有難以置信的魅力。

除了 Rails，比起其他腳本語言，JRuby 項(xiàng)目和現(xiàn)有的 Java 代碼很好或更好地集成到了一起。事實(shí)上，JRuby 也許會超越標(biāo)準(zhǔn) Ruby 分布，并成為 Ruby 程序員們更偏愛的平臺，而不止是 Java 程序員們將 Ruby 作為第二種選擇。這很好。Python 程序員們會這樣反對：他們這些年來已經(jīng)將 JRuby 最好的方面加入到 Jython 中，他們是對的，但我討論的是 2007 年將 發(fā)生什么，而不是應(yīng)該 發(fā)生什么。這很不幸但卻是事實(shí)：Ruby 獲得了契機(jī)，而 Python 沒有。

其他腳本語言會被逐漸逐出界外。Perl 太過時了，不能很好地適應(yīng)現(xiàn)代應(yīng)用程序。Groovy 缺少明確的視角，還趨向于將計(jì)算機(jī)科學(xué)的時髦用語凌駕于可用性和熟悉性之上，這讓它深受其苦。BeanShell、Jelly，還有半打其他語言可能都從未吸引過超過一個的稱心追隨者。來年的這個時候，到處都會是這樣的吶喊：Ruby 將成為 Java 程序員們首選的腳本語言。

回頁首

集成開發(fā)環(huán)境（IDE）會變得更好

一批垂死的 IDE 真正點(diǎn)燃了 2006 之火，再一次證明競爭是好事。由于 Eclipse 造成的窘境，Sun 將一些能量和資源注入到 NetBeans 當(dāng)中，最終開始了一場貌似激烈的競爭。通過采取一些措施，到 2006 年底，NetBeans 甚至超越了 Eclipse。它針對設(shè)計(jì) GUI 具有卓越的原生化外觀和出色得多的工具。它所不具有的是 Eclipse 社區(qū)。相比 NetBeans，更多的插件和第三方產(chǎn)品是基于 Eclipse 的 —— 至少從量上更多 —— 并且這種趨勢僅呈加速之勢。

來年，Eclipse 會努力開發(fā) 3.3 版，應(yīng)于 2007 年發(fā)布。Sun 也可能成功地將 NetBeans 6 公諸于世。這兩個版本都不太可能是重要的版本：它們只是關(guān)注于添加這里或那里的小功能、修復(fù) bug 和簡化用戶界面（盡管可能還沒有做到應(yīng)該要做的那么多）。

NetBeans 可能將繼續(xù)贏得 Eclipse 的市場份額。這是從很早以前就開始了的，這方面還有更大的增長空間。（Sun 無情地推動 NetBeans 和 JDK 下載并沒傷害到任何一個）。到本年度結(jié)束時，兩種 IDE 也許將瓜分這個市場，平分天下。

同時，自信滿滿的 IntelliJ IDEA 用戶將繼續(xù)疑惑于這一團(tuán)混亂的場面。他們的信念是：IntelliJ IDEA 是最好的 Java IDE。盡管如此，大多數(shù)用戶不會對 500 美元的標(biāo)價視而不見，因此其市場份額將繼續(xù)在 5% 上下波動。

回頁首

Java 企業(yè)版

沒有哪部分 Java 編程像 JEE 這么成功，也沒有哪部分 Java 編程像 JEE 那樣招致如此多的斥責(zé)。它是一門每個人都喜歡去討厭的技術(shù)。它復(fù)雜、費(fèi)解并且是重量級的。沒有哪部分 Java 編程有這多么第三方努力將其整個替換或部分替換：Spring、 Hibernate、Restlet、aspects、Struts …… 等等。雖然如此，幾乎每一個招聘 Java 程序員的商家都要求其有 JEE 經(jīng)驗(yàn)，因此 Sun 確實(shí)是正確的。

在企業(yè)級領(lǐng)域里，我能看到的全部趨勢就是簡單。大塊頭的框架出局；小而簡單的加入了進(jìn)來。隨之增長的是，客戶拒絕大塊頭的 JEE 棧部分，這種趨勢還在繼續(xù)。作為替代的是，客戶轉(zhuǎn)向了像 Spring 這樣更簡單的框架或者完全脫離 Java 平臺而投向 Ruby On Rails。對于更簡單、更易理解的系統(tǒng)的需求也驅(qū)動著對面向服務(wù)架構(gòu)（SOA）和具象狀態(tài)傳輸（Representational State Transfer, REST）的興趣。

我們能夠預(yù)料出，朝著簡單發(fā)展的趨勢在 2007 年將會延續(xù)。許多對 Rails 留下印象的人正試圖在其他語言上復(fù)制它的成功，比如 Python (Turbo Gears)、Groovy (Grails) 以及 Java (Sails)。這其中的某個有可能成功，但它們?nèi)绻惶岢鲆恍?qiáng)有力的新舉措的話，就不會取得成功。因此，企業(yè)仍將加載他們已有的框架：SOA、REST 和 Rails。

回頁首

Java 微型版（Java Micro Edition, Java ME）

將視線從最大平臺移到最小平臺上來，我們能期待嵌入式世界帶給我們什么？多年以來，Java 平臺已經(jīng)在小設(shè)備上取得了相當(dāng)大的成功，而 2007 很可能會以這一成功為基礎(chǔ)。首先，關(guān)注一下移動信息設(shè)備描述（Mobile Information Device Profile，MIDP） 的第 3 版，來利用當(dāng)今更為強(qiáng)大的設(shè)備的功能。特別是，我們應(yīng)該很快就能在一個虛擬機(jī)上運(yùn)行多個 MIDlet，包括在后臺運(yùn)行一個或多個。同樣也關(guān)注一下加密記錄管理系統(tǒng)（RMS）存儲和 IPv6 支持。

Java ME 的可擴(kuò)縮的 2D 矢量圖形（Scalable 2D Vector Graphics, SVG）API 2.0 當(dāng)前正在開發(fā)中，它應(yīng)擴(kuò)展在許多設(shè)備中的動畫功能。除 SVG 動畫之外，它也將支持流式音頻和視頻。如果移動網(wǎng)絡(luò)開放，這是相當(dāng)重要的 —— 想想在手機(jī)上的 YouTube。（當(dāng)然，如果網(wǎng)絡(luò)開放，那就只是沒人愿意看的兩英寸的公司廣告。在這點(diǎn)上，我對美國的情況持悲觀態(tài)度，而在歐洲也許會更有趣。）

移動開發(fā)者也能期望本年推出第一款支持 Java ME 的 XML API 的手機(jī)。此 API 是 SAX、DOM、 StAX 和 JAXP 的一個精選子集，設(shè)計(jì)它是為了適應(yīng)內(nèi)存受限的手機(jī)。許多人認(rèn)為真正的 XML 不適合手機(jī) —— 他們是對是錯今年就能見分曉。

盡管好事連連，Apple 的 iPhone 仍對 Java 平臺（作為移動電話開發(fā)平臺）構(gòu)成了一個主要的威脅。iPhone 已經(jīng)是這個星球上最火爆、最有魅力的手機(jī)，它已經(jīng)發(fā)布了六個月。問題在于它將成為一個相對封閉的平臺，甚至按手機(jī)網(wǎng)絡(luò)標(biāo)準(zhǔn)也是如此，并且它沒打算運(yùn)行 Java 代碼。無需多說，對于任何試圖向手機(jī)、PDA 和個人通訊設(shè)備推銷第三方應(yīng)用程序的人來說，這都是一個恐怖的消息。

回頁首

結(jié)束語

由于 JDK 的開源，2007 注定成為自互聯(lián)網(wǎng)炸彈（dot bomb）以來 Java 編程界最令人激動的年份。截至目前，Java 平臺一直被 Sun 公司的目標(biāo)和投資能力所制約，但這種情況即將改變。有了開發(fā)者社區(qū)掌舵，我們有望看到 Java 編程全方位發(fā)展，而這種發(fā)展很可能突然出現(xiàn)。開發(fā)人員將使用 Java 代碼（以及針對 Java 代碼）完成比以往更多的任務(wù)。桌面、服務(wù)器以及嵌入式：一切都會加速！是的，在這個過程中會有一些重大的失敗，但失敗也是樂趣的一部分！好的想法將脫穎而出，不好的將被淘汰。如果您對 Java 平臺有任何不滿意，或者有一直迷惑的地方，啟動您的 IDE，開始改造吧！

女士們、先生們！啟動您的編譯器吧！