如果您曾經http://www.javasoft.com ;網站上查詢有關Java 2 Micro Edition 的資料,十之八九會被一大堆的技術名詞搞的一頭霧水。什麼 KVM ,什麼CLDC 、CDC 、MIDP ,後面面還冒出了Personal JAVA、Embedded Java以及JES 等名詞。雖然名為JAVA的微小版本,可是它的世界可真是不小,讓我們滿肚子“見山不是山,見水不是水”的疑惑。的確,在我剛開始接觸 Java 2 Micro Edition 的時候,就感覺到這個玩意兒實在越看越讓人摸不著頭緒。
因此在本文中,我捨棄了技術上的細節,希望帶大家從宏觀的角度來看待 Java 2 Micro Edition 的世界。希望讀過本文之後,可以使大家體驗“見山是山,見水是水”,一切豁然開朗的感覺。首先,我們必須先對Java 2 Micro Edition 在整個JAVA技術之中的定位做個瞭解。
各種不同版本之JAVA程式的開發
如前面所說,各種不同的JAVA版本,在其支援的核心類別函式庫之完整性以及所支援的 JAVA基本型別這兩件事情上都有所差異,也就是說,不管您開發的是企業所使用的JAVA程式、嵌入式裝置上執行的JAVA程式、瀏覽器上執行的Applet ,或是在PC 上執行的應用程式。您都必須在您的電腦上先安裝 J2SE ,然後再安裝各種版本的核心類別函式庫以及額外的擴充類別函式庫,如此才能成功地開發各種不同目的的JAVA程式。
J2SE所提供的JAVA編譯器(javac.exe)可以協助我們編譯各種不同平台上的JAVA程式,而J2SE 所提供的JAVA虛擬機器(java.exe)則可以協助我們在PC 上先行測試這些程式執行結果的正確與否。
另外,JAVA編譯器並不會幫您檢查您的程式是否符合各種平台上所支援的核心類別函式庫與 JAVA基本型別。舉例來說,雖然我們在前面說過,Smart Card 版本並不支援boolean 、byte 以外的JAVA基本型別,而且該平台也只支援java.lang.* 核心類別,可是當我們在撰寫 Smart Card 平台上的程式時,就算在程式碼裡用了boolean 或byte 以外的JAVA基本型別,或者使用了java.lang.*之外的其它核心類別,編譯器仍然可以照常幫您編譯出類別檔。
這個時候大家一定開始產生疑惑——那麼這些程式如果放到Smart Card 上頭執行的時候,出了問題怎麼辦 ? 難道不會造成Smart Card 上的虛擬機器執行時發生錯誤嗎 ? 針對這個可能發生的潛在問題,Sun Microsystems 在各種不同版本的開發套件中,有些會內附檢查器 (checker)或者預先審核器 preverifier),這兩個工具可以協助您在將程式放到目標平台之前先做好檢查和預先審核的工作。檢查器會幫您找出類別檔之中不合目標平台規格的部分,並提醒你這些地方可能無法在目標平台上執行。因此只要有檢查器的協助,您大致上可以確定您的程式可以符合目標平台的規定並順利執行。 Java Card 的開發套件中就附有檢查器。
而某些平台的開發套件則附有預先審核器,預先審核器除了做檢查器做的工作之外,還有一項額外的工作,就是減輕目標平台上虛擬機器的負擔,要解釋預先審核器這個額外的工作,在傳統的 JAVA程式之中,為了安全上的考慮,任何進入執行環境的類別檔 (不管該類別檔是來自本機或是遠端機器 ),都必須先經過Byte Code 審核器(Byte code verifier)的驗證,以防止程式在傳送途中遭到惡意的修改,而使得 JAVA程式在執行時對系統有不良影響。
經過審核之後,該類別檔才能開始被J 虛擬機器所執行。如果這個審核的動作在一般的 PC 上執行,速度倒是還能夠接受,可是一旦放到如 Palm 或是手機這些CPU 較慢、記憶體也比較少的機器上面就顯得十分吃力了。為了節省寶貴的 CPU 運算時間(既能省電又能夠加速程式執行 ),因此,在程式設計師產生能夠讓某些特定平台執行的類別檔之前,程式設計師必須先在 PC 上使用預先審核器做一些前置的審核工作,預先審核器會在類別檔之中加入一些特殊標記或符號。如此一來,當這些程式放到目標平台上執行時,就可以大幅減少在目標平台上做審核時的時間,藉而加速程式的的啟動及執行速度。因此在J2ME 之下的程式(Spotlet 、MIDlet),其執行步驟變成因為預先審核的關係,執行時Byte Code,審核器的工作就變少了,也因此從程式載入到開始執行之間的時間因而縮短。 CLDC標準實作和MIDP 參考實作之中就附有預先審核器。
JAVA版本的演化
相信熟悉JAVA演化曆史的人或多或少都聽說過,JAVA技術一開始並非就叫做 JAVA,而是叫做OAK ,而且最早的時候就是為了嵌入式系統而設計的一項產品。後來因為網際網路的發達,而OAK 的諸多特性剛好又適合用在網路上(例如可移植性、編譯後程式碼很小),因為商標已被註冊的關係,因此 OAK 被改名成JAVA,從此因緣際會地成了網路上的閃亮巨星,並隨著時間越來越成熟,也慢慢地產生了許多非原本預期中的相關運用。
雖然 JAVA已經被用到許多企業級軟體上,可是其實骨子裡面還是非常適合用在嵌入式系統之中。
雖然從Java 1.0 發表之後,JAVA就被廣泛地使用在桌上型應用程式以及Applet 的開發上,但是,從Java 1.1 開始,Java又回到了它一開始的老路--也就是嵌入式系統方面的應用,在當時Sun Microsystems 發表了Embedded JAVA與Personal Java(也有人簡稱為PJava)這兩項規格。其中Embedded JAVA是為了資源十分有限,而且沒有顯示裝置的嵌入式裝置而設計;Personal JAVA則是為了在能夠與網際網路連線、並擁有顯示系統(例如彩色LCD)的消費性電子裝置而設計。接著JAVA的版本演化到Java 2 ,這時為了再明顯區分各種JAVA的應用,所以分割出了J2EE、J2SE、以及 J2ME 三種版本。
這三種版本的各種特性我們已經在前面已經詳細地描述,在此不再贅述。不過請大家記住,由於 Java 2將JAVA的應用區分成三大塊,使得 JAVA程式語言的發展不會再像Java 1.1時如樹枝狀般擴散出去,這麼一來有助於大家對 JAVA各種應用的瞭解,而不會造成今後越發展下去越不可收拾的混亂局面。額外向大家一提的是,後來Personal JAVA發展到1.2 版的時候,也採用了一些Java 2 平台上與安全性有關的設計。
Java 2 Micro Edition 概念
J2ME 在設計其規格的時候,遵循著「對於各種不同的裝置而造出一個單一的開發系統是沒有意義的事」這個基本原則。於是 J2ME 先將所有的嵌入式裝置大體上區分為兩種 :一種是運算功能有限、電力供應也有限的嵌入式裝置(比方說PDA 、手機);另外一種則是運算能力相對較佳、並請在電力供應上相對比較充足的嵌入式裝置 (比方說冷氣機、電冰箱、電視機上盒 (set-top box))。因為這兩種型態的嵌入式裝置,所以JAVA引入了一個叫做Configuration 的概念,然後把上述運算功能有限、電力有限的嵌入式裝置定義在Connected Limited Device Configuration(CLDC)規格之中;而另外一種裝置則規範為 Connected Device Configuration(CDC)規格。也就是說, J2ME 先把所有的嵌入式裝置利用Configuration 的概念區隔成兩種抽象的型態。
其實在這裡大家可以把Configuration 當作是J2ME 對於兩種類型嵌入式裝置的規格,而這些規格之中定義了這些裝置至少要符合的運算能力、供電能力、記憶體大小等規範,同時也定了一組在這些裝置上執行的 JAVA程式所能使用的類別函式庫、這些規範之中所定義的類別函式庫為 JAVA標準核心類別函式庫的子集合以及與該型態裝置特性相符的擴充類別函式庫。比方就CLDC 的規範來說,可以支援的核心類別函式庫為java.lang.* 、java.io.*、java.util.*,而支援的擴充類別函式庫為java.microedition.io.*。區分出兩種主要的Configuration 之後,J2ME 接著在定義出Profile的概念。Profile 是架構在Configuration 之上的規格。之所以有Profile的概念,是為了要更明確地區分出各種嵌入式裝置上JAVA程式該如何開發以及它們應該具有哪些功能。因此Profile 之中定義了與特定嵌入式裝置非常相關的擴充類別函式庫,而 JAVA程式在各種嵌入式裝置上的使用者介面該如何呈現就是定義在Profile 裡頭。Profile 之中所定義的擴充類別函式庫是根據底層Configuration 內所定義的核心類別函式庫所建立。
JAVA在嵌入式系統上的應用
由於JAVA本身最初的設計理念即是針對嵌入式系統,因此將他用在嵌入式系統上真可謂如魚得水。在這個Linux 開始興起的時空交會點,網路上出現了一篇關於嵌入式 Linux 與JAVA互相配合以造就雙贏局面的相關報導,這是由 LinuxDevices.com 的專欄作家 Randy Rorden 所發表的一篇白皮書,名為「 JAVA與嵌入式 Linux 合作」。 在這篇文章裡頭,作者對嵌入式Linux與JAVA個別的優點提出他的看法,同時也提出了Java-Linux 平台的構想。有興趣的讀者可以到到下列幾個網站參考相關新聞與資料。
1. JAVA與嵌入式 Linux 合作白皮書http://www.ctech.com.tw/d-news/news/linux/89090208.asp ;
2. JAVA及嵌入式Linux 合作http://www.linuxdevices.com/news/NS5973673868.html ;
3. 即將來臨的Java-Linux 結合http://www.linuxdevices.com/articles/AT7102892618.html ;
為何要用JAVA撰寫PDA 上的應用程式?
由於預期到今後行動通訊時代的來臨,所以通訊相關行業變的前景可期,而除了達成行動通訊的主要工具 -- 手機月來越精巧之外,有更多的廠商相繼投入PDA 的生產與開發。本來PDA 主要的平台有PalmOS 、Windows CE 以及EPOC ,也不知道曾幾何時,開始一大堆公司投入embedded linux 的研發,其中包括國內資策會自己開發的 @ViS 作業系統,互慧科技也有自己的嵌入式作業系統,當然更不用說大陸廠商與韓國廠商了。
這些作業平台的數量比起 PC 來說真不知道要複雜上幾倍。對一般使用者來說當然影響比較小,可是對於程式開發人員來說,看到這麼多不同的程式發展平台,真是讓人望之卻步。如果每個平台都有自己的程式寫法以及函式庫,那麼光是看上面這些平台至少就要學習五種以上程式的寫法。當然,只專精一種平台當然是很好的事情。可是程式設計師不禁要說 :”如果我們寫出來的軟體可以在不經過修改原始碼的情況下就能夠在這些平台上執行,那不是更完美嗎?” 對程式開發人員來說,這樣的投資報酬率當然是最大的。
要在那麼多平台上開發程式,對程式設計師來說的確是一個很大的挑戰,如果要把所有的時間和精力放在軟體的可用性上,那麼相對地很多時候我們根本沒有那麼多時間撰寫各種平台的程式。要解決這個問題,一般來說程式設計師會選用一個可以跨平台的Framework 來達成至少source code level 的跨平台(例入Qt 就能做到)。不過在本篇文章中我們要介紹的則是更終極的解決方案 ?Java ,利用JAVA的”write once, run anywhere”特性,我們可以真正達到程式只要寫一次,拿到任何平台上都可以執行(當然前提是必須要PDA 的廠商也要實作出該平台的Java Virtual Machine 才行)。利用JAVA來做PDA 上的程式當然有其缺點,最廣為人知的可能就是執行效率的問題, JAVA在執行速度這個議題上一直讓人詬病。
不過筆者認為,隨著技術的發達,將會有更快更省電的PDA 專用CPU 出現,因此效率上的問題其實是可以忽略的。更何況,當 Sun 在設計J2ME 的時候,也用了很多方式企圖加快JAVA在PDA 上的執行速度(例如預先審核)。