談到Java，大家都說這是最有「錢景」的語言，不過再談下去，大家恐怕就會安靜下來，因爲執行的速度實在太慢了，慢到即使現在的CPU都已經上GHz等級的時代，大家還是有志一同的說：這個語言還有改善的空間。 我們翻開Java的歷史來看看，在1991年Sun Microsystems Inc. 的綠色計畫（Green Project）打算髮展消費性電子產品，原本使用C、C++語言當作計畫的主軸，但後來發現這些語言的功能，無法達到他們的理想目標，加上網路興起的因素，隨之就與有志之士着手設計一套完全物件導向，且不受平臺限制的語言，原本以公司外面那一棵橡樹之名稱這套語言爲oak，然這個名字又已經有人使用，於是設計小組最後突發奇想，以開會時的咖啡廳之名命之，此即爲Hot Java的由來，所以我們看到其圖樣有杯熱滾滾的咖啡！ Java爲什麼稱爲最有前景的語言呢？原來他具備了所有程式設計師的夢想特色，「跨平臺的語言」、「極佳的安全性」、「適合網路應用」、「容易撰寫應用程式」，甚至昇陽公司的執行長Scott McNealy還做出一個結論：『Write once, run anywhere on anything safely』。 圖、Java系統結構圖 不過爲了達到這些目的，Java採用了兩個部分組成整體架構，即虛擬機器（Virtual Machine）和應用程式介面（API），我們可以把虛擬機器看成是一套虛擬的電腦，就是說用軟體來模擬一個電腦，但是因爲這個Java虛擬機器是以堆疊機器(Stack Machine)的概念作成，這也就是說，以1+2=3爲例，Java虛擬機器會先把運算元，也就是1與2放入堆疊中，在一一由堆疊頂端拿出來做運算，運算結果(也就是3)再放進堆疊中。原本普通只要一個CPU指令就可以做完的動作，卻因爲還要作堆疊的動作，花了四、五個指令才能做完，造成效率不彰。 前面筆者不是提到綠色計畫不就是爲了發展消費性電子產品而誕生的嗎？那Java如此的現況，還是合適發展消費性電子產品嗎？答案當然是肯定的，最近這一兩年來，由於行動終端裝置的蓬勃發展，不僅使用的人口日益擴增，連帶使得加入發展的軟硬體廠商也洶涌而至。各式各樣的硬體設備，軟體平臺都被開發出來以加入這一場21世紀的行動通訊大戰。在硬體裝置上有Intel公司的StrongARM系列，Motorola公司的Dragon ball系列等等；軟體平臺則有着名的Linux作業系統，Microsoft的Pocket PC，Accelerated Technology公司出品的Nucleus PLUS等等。因此在一個擁有這麼排列組合的環境下，一個程式設計師如果想要撰寫出能夠橫跨這麼多平臺的應用程式出來，那將是一件不容易的事情。所以我們不禁要佩服昇陽公司能夠早在十年前就可以預料到現在的狀況，而發展Java語言。 因此針對消費性電子產品與其他桌上型電腦之間的不同，昇陽公司不再要求Java必須統一，而是針對不同平臺特性，發展不同的版本，這也就是目前大家耳熟能詳的Java2的由來。在Java2裏面，針對小型的消費性電子產品，特別制訂了一個版本，稱爲J2ME(Java 2 Platform Micro Edition)，這是爲了市場日漸壯大的資訊家電設備在2000年所發展出來的微型Java技術，主要的應用可以分爲兩大類，個人行動裝置和共用固接裝置。其中專爲J2ME所發展的虛擬機器就是KVM(K Virtual Machine)，這是爲了在有限系統資源下執行Java 應用的虛擬機器，對記憶體的需求量在Kilo Bytes等級裏故命此名之。圖、Java應用運作流程 爲了突破效率上的障礙，深入研究這種專爲嵌入式產品所打造的KVM實作恐怕是必須的，傳統的Java程式採用了一些特別的方法來解決效率的問題，Just in time Compiler（JIT compiler）針對Bytecode需執行時纔去翻譯，如上圖所示，但是在KVM中，必須要更簡化這些流程，例如KVM把byte code verify的動作分成兩步，先用預先審覈器(preverifier)做一些前置的審覈工作，預先審覈器會在類別檔之中加入一些特殊標記或符號。如此一來，當這些程式放到目標平臺上執行時，就可以大幅減少在目標平臺上做審覈時的時間，藉而加速程式的的啓動及執行速度。所以KVM的應用程式發展流程就會像下面這張圖的流程一樣，比起一般的Java程式開發來說，多了許多的步驟。 圖、Java 程式發展及載入具有KVM 的目標平臺的流程 另外一招，既然效率問題卡在KVM本身，所以我們可以選擇就針對KVM作許多最佳化的動作，昇陽公司的KVM參考實作是採用C語言，我們可以仔細分析這個參考實作，把一些瓶頸部分改採用組合語言來撰寫，或是開啓一些效能選項，讓KVM本身的效率變快，不過根據筆者初步的實際測試，這招可以讓整個KVM效能上升約10% - 20%。 如果KVM也調整了，效率還是不佳呢？還有一招，就是把Java method改成用native code實作出來，這個方案的中心想法是：native code並不需要經過interpreter的解釋而是直接送給作業系統執行，所以它避開了效能瓶頸的Java虛擬機器，因此可以提升整體的執行效率。不過這招的問題是目前的J2ME中並沒有包含JIT的功能，因爲如果要再系統資源缺乏的小型裝置上實作出這種機制出來的話，將會大幅的降低J2ME的可用性。 <<到底什麼是native code？>>讀者可以把它想像成使用傳統C語言所撰寫而成的程式碼。因爲使用C語言所撰寫而成的程式碼可以被編譯成底層硬體看的懂得機械碼，就好像是機器的母語一樣，所以我們把它叫做native code。相對來說，由於使用Java語言所撰寫而成的程式碼只能在Java虛擬機器上執行，不能直接被底層的作業系統與硬體所執行，因此會造成效率上的落差。其實，任何一種程式語言，只要使用該程式語言所撰寫而成的程式碼，可以被該種語言的編譯器編譯成底層硬體所能看的懂得機械碼的話，使用該種程式語言所撰寫而成的程式碼都可被稱爲是native code。不過一般說來native code都是指傳統的C或C++程式語言。 最後一招就是Java Byte Code Interpreter ，使負擔最重的的部分由硬體去解決，就是我們常聽到的Java Chip，如JavaSoft 與Sun Microelectronic 的PicoJava，MicroJava 和 UltraJava晶片以及ARM公司的Jazelle的技術，這招就是最後絕招了，而且實際的效率也真的讓人滿意。由於手機市場上面，目前ARM佔了絕大多數的市場，因此一旦ARM所推出具有Java硬體加速的CPU廣爲手機製造廠商所使用，將來可以預期的就是具備Java功能的手機將會更爲普及。 圖、Jazelle系列晶片上的軟體架構。（資料來源：http://www.arm.com ） 經過這一大串的解釋之後，可能讀者開始抗議，爲什麼講這些東西呢？其實筆者只是想指出一個已經存在的現象，在目前的Java手機中，都已經號稱可以執行一些Java的程式了，不過經過上面的解釋之後，讀者再來想一想我們拿到用來在Java手機上所執行的程式，會不會赫然發現只有一些簡單的遊戲程式？比較複雜的程式幾乎可以說不存在。講到這邊一定有讀者開始抗議，中華電信不就配合Motorola太極二代的Java功能，推出一款類似股票機功能的服務嗎？沒錯，這大概是筆者目前發現比較實用而且複雜的程式，不過如果讀者想要把這支股票服務的Java程式拿到其他廠牌的Java手機，例如說是西門子的Java手機上面，是否可以執行？很不幸的，筆者必須誠實的說：「不行」！不然爲什麼中華電信到目前爲止還只能夠在太極二代上面使用這項服務，而無法廣爲讓各種手機一起使用呢？ 那讀者一定要開始抗議，Java程式不就是號稱可以跨平臺嗎？怎麼變成這樣呢？其實道理在前面都描述過了，就是因爲複雜的程式或多或少都會用到一些該手機或是平臺纔有的一些特殊功能，這些並沒有定義在標準的Java規範當中，但是卻是合法可以使用的部分，就算通通都沒有用到好了，光是顯示螢幕的大小就夠程式設計人員頭痛不已了。 舉另外一個例子來說，在J2ME的範圍裏面，PDA和手機是擺在一起的，現在在Palm或是iPAQ上面已經有不少的Java程式，而且許多程式本身也相當具有份量，但是直接放在Java手機上面執行看看，先花了大把的功夫把Java程式放到手機裏面，就需要花費許多時間來研究，不信你看看現在那一本J2ME實作的書籍或是文章有告訴你這個步驟怎麼作？全部都是使用Sun公司所提供的模擬器當程式範例與模擬而已，可是連放上手機執行都不那麼的直觀，提供下載的地方也寥寥可數，這個技術的應用程度還是有待考驗。 經過千辛萬苦，搞了半天，終於塞到手機裏面去，結果竟然不能夠執行，最後還是隻有一些簡單的遊戲可以跑，這個痛苦的經歷真可呼應昇陽公司的執行長Scott McNealy的名言來個對句：「Write once，debug everywhere」，也因爲目前的技術如此的不切實際，因此這對於想要積極投入這方面的人來說，可能還是先等一等比較好。 至於手機廠商有沒有看到這些問題，當然有羅！許多研究單位正積極研究到底如何才能夠兼具效率與操作的方便度？爲了拉近Java程式與真實手機之間的搭配，許多的規格也紛紛出籠，手機廠商之間的各種聯盟與合作計畫也正如火如荼的展開當中，相信在過不久，這些問題都會獲得適當的解決。 用Java程式語言所撰寫出來的應用程式之所以能夠跨平臺執行，在背後其實有着數十種不同的機制在運作。不論是獨特的內部組譯迴圈，特殊的Java class檔案結構，最初的啓動載入的機制等等，這些看起來與傳統程式語言差異很多的部分，其實不僅構成了Java軟體環境的核心，而且在實際去了解它們的運作機制之後，更能加深讀者們在運用Java程式語言撰寫應用程式的能力。有一句話是這樣說的：沒有看過Java虛擬機器的內部，不能說是完全的瞭解了Java程式語言。在這個量身定作的KVM裏面，更值得大家一探嵌入式Java虛擬機器！ 參考資料： 深入嵌入式爪哇虛擬機器 – Inside KVM, 探矽工作室
