Java是在C++基礎上改進了的面向對象的語言。它可以得到類的封裝、繼承、多態等的優異重用性的好處，Java的小應用程序（Java Applet）還特別適合于上網。看來，用Java開發上的網的嵌入式應用應是很理想的，可惜，實現起來受嵌入式設備硬件在速度、存儲器容量、和其它資源的限制，加上桌面Java語言操作不到硬件，和執行時間的不確定性，使Java應用于嵌入式系統遇到新的問題。Sun公司按PersonalJava規范開發的J2ME（Java 2 Micro Edition），是專用研制用于開發嵌入式的上網個人消費類設備的。因此J2ME除有面向對象的優點外，還包含了Web能力。J2ME使用的是Java API的一個子集，它僅保留了API的關鍵特性并適當地作了簡化。同時，又規定了兩種可有存儲模式：一個模式的內存為128～256KB，另一種模式是 256KB以上的。其他，如類包也根據存儲模式選用。

下面為避免混淆，在文中凡未加特殊說明的Java，統指桌面Java而言。

一、 問題提出

*常用的解釋性Java(Java Applet)的執行速度慢，不適于嵌入式的應用。

*Java要求過大的內存。

*嵌入式設備要求操作硬件。因Java廢棄了C語言所使用的指針，且在Web環境下使用了Java虛擬機（JVM），使Java無力直接甚至間接地用指針操作硬件。

*Java使用一些自動功能會引起執行時間的不確定性，成為嵌入式的大忌。如垃圾自動收集器。本是對于C的重大改進，但卻因程序自動地回收垃圾，從而引入了實時的時間不確定性。

二、解決方案

使用AOT編譯器

為解決解釋性Java(Java Applet)執行速度過慢的問題，發展了AOT（ahead-of-time）編譯器。大家喜歡在Internet上使用Java的一個原因是其字節碼具有跨平臺性，即同一Java代碼可以運行于PC、Mac、Solaris，甚至于主機之上。為此，在英文叫它WORA（寫一次即可通行于任意機）。這是因為每一操作系統平臺上都有符合自己機型的專用Java虛擬機（JVM），由它對字節碼進行解釋運行。因為解釋程序需先被解釋再被執行，多了解釋環節，延誤數秒鐘時間。如果是撥打電話，這個時間足以令人生厭。現在使用AOT（ahead-of-time）超前編譯器，提前將解釋碼轉換為本平臺所用的并經優化過的二進制碼，速度提高很多。現有Cygnus公司聲稱，它開發的AOT編譯器執行速度是原解釋程序的8倍。NewMonics說它的 QuickPERC編譯器是原解釋程序的20倍。當然，AOT編譯器也有不足，就是他犧牲了Java的WORA。

減少內存的占用

所有的面向對象語言，比C及匯編語言點用內存都多。這個問題對于桌面系統早已不再是考慮的因素了，如服務器平均占用數GB的內存已司空見慣。但是，對于嵌入式系統卻不能不考慮。用Java開發的信息家電產品可能需要把內存限制到512KB以下。如果嵌入式系統使用的是規模為1MB的核心類庫，那就是說，一句代碼尚未寫，內存早就不夠用了。

為此，需要把用不到的類、類方法和代統統從程序中剔除。（AOT超前編譯器可以幫助解決這個問題。）再就是自己開發本平臺專用的，既短小高效、又符合Java API標準的Java核心類庫。

開發能混合編程的IDE

一般認為，用C語言寫的程序，指鍺使用不當引起的缺陷占總缺陷的80%左右。Java語言，出于安全的考慮，才廢棄了使用指針。但是，指針卻能夠最直接地訪問到存儲器和真實的硬件。現在，為在嵌入式Java中能夠訪問到硬件，不得不改用本地接口，即從嵌入式Java中利用能夠訪問到硬件的C語言函數來實行交叉編程。這就意味著增加了復雜性。開發人員需要具備多語言以及多層次的混合編程和混合調試的能力。發展多語言多層次混合編程的IDE，無疑十分有助于一般開發人員完成這一相當復雜的課題。Metrowerks的CodeWorrior和IBM的VisualAge就是新開發的基于J2ME的這樣的IDE。

克服時間的不確定性

Java 最主要的問題是時間不確定性，主要來源于存儲器殘渣的自動收集再生器。這種垃圾收集再生器工作的時候，自動地決定何時停下其他程序的執行，再根據當時殘渣的實際情況或長或短地完成任務。所以，它嚴重地干擾實時應用所要求的時間確定性。為解決這一問題，不同公司采用不同的方法和垃圾收集的算法。 NewMonics的Real Time Executives和Windriver的FastJ都是保證絕對的確定時間，Sun公司用不同的辦法但也保證具有實時的確定性。采用不同的編程技巧，譬如使用類型確定的線程局部存儲，也可以避免因垃圾收集引發的沖突。

需保持跨平臺的必要

AOT 編譯器生成的Java代碼喪失了Java在其他操作平臺上的執行能力。要想把Java的源代碼再向其他平臺移植，需要附加很大的勞動。面向對象的一個基本設計原理就是只要保持接品不變，那么，與接口交談的代碼在移植時就不受影響。所謂高級邏輯接口的隔離手法，事實上，就是將平臺敏感的內容同移值無關的代碼分離開來，并且分別提供同樣功能的平臺敏感程序。現在，針對嵌入式Java，目前還沒有人做這項工作。

三、實際應用

Java是良好的嵌入式編程語言嗎？

還不能這么說，至少現在是這樣。因為在嵌入式系統中，Java如何應用要看具體情況而定。對于需要管理中斷來完成重要任務的應用系統，就不宜于選用Java 進行開發，譬如引導登外星的飛行器系統就是這樣。對于要求輕型、高效、任務重要、時間確定性要求極高的系統，也是只能局限于使用C語言和匯編。比如，點燃登陸外星的制動火箭系統，定時通過串行口獲取關鍵信息一邊做出決定的系統，定時報告航天器方位的系統等都不能使用Java。但是，需要不斷與他人通信聯系，以便對貨運進行有效管理的手持系統，又最適合使用Java編程。因為，它既發揚了Java Applet固有的跨平臺應用地Web環境的特點，又能充分利用服務器端的現成軟件。

使用Java有時也并不完全取決于技術

立足于經濟上的考慮，比單獨的技術考慮更為重要。譬如，對于服務器，為了支持使用Java，寧愿多花費數千元擴大存儲器是正確的。因為，從投入/產出的分析也得出同樣的結論。又如手機，若為支持使用Java，哪性僅只需要多花一元錢去擴大存儲器也是不可行的。因為，手機的生產是以行百萬件的產量來考慮的，多花一元線，就意味著多花千百萬元，諾大的數字遠比技術的先進更為重要，是顯而易見的。

實施嵌入式Java時需注意

Java 用于嵌入式還是瓣生事物，需要探路前進，摸著石頭過河，忌冒進和全面開花。應試探性地從使用現成的嵌入式J2ME開始，在它的通用性的開發環境下運行本平臺的字節碼。盡可能地順著J2MME向前走，盡可能地順著J2ME向前走，盡可能地走得遠一點，只有在遇到特殊問題時才導求新的解決辦法。新方法的采用并不一定能夠解決問題，比如，AOT或半自動的垃圾收集器等可能并沒有解決你的問題，也勿驚慌，要總結經驗做出評價，繼續前進，使嵌入式Java日罄完善。

要重視IDE的選用，好的IDE絕對是良好的助手。否則，你是單槍匹馬，披荊斬棘，艱苦良多。