嵌入式Java會在下一代移動電話、智能卡、無線設備、游戲裝置及其他許多嵌入式應用中扮演重要角色，關鍵在于選擇哪一種實現方法。
Java自從推出以來一直備受關注，不過在嵌入式系統設計師看來，其性能并不能令人滿意。運行Java虛擬機（JVM）解釋Java字節碼這種方式對大多數嵌入式應用來說占用空間過多，運行速度過慢。不過Sun的Java 2 Micro Edition（J2ME）改變了這種狀況。
對嵌入式系統設計師來說，Java有許多優點。作為一門編程語言，Java允許面向對象編程，又沒有C++中存在的嚴重問題。例如，Java允許類繼承，但不允許來自多個父類，這就排除了產生混淆的可能；同樣，Java防止了C++定義運算符時允許出現的不確定性。Java運行時環境還提供了有用屬性，它通過先檢查JVM中的代碼然后再執行來確保應用程序不會相互干擾，以及整個系統不會崩潰，如果代碼試圖改變系統的核心行為，它就無法運行。Java提供的內存管理功能使得編程人員不必分配及釋放內存，避免了內存泄露的可能，它還能通過垃圾收集方法，自動釋放閑置內存。運行時環境甚至可以通過整合核心類庫來簡化程序分配。
此外，Java在業界得到了廣泛支持，這意味著有眾多資源可以利用，包括小應用程序和經驗豐富的編程人員，從而每次編寫新應用程序無需重復性工作。
但在上述這些優點之外，Java用于嵌入式開發的問題在于，大多數嵌入式應用面臨Java沒有處理好的兩大約束：沒有足夠的空間和時間。
Java開發的時間和空間約束
之所以會有時間上的約束，是嵌入式系統通常必須在短時間內對外部事件做出響應，如果系統在下一個事件出現前沒有處理好前一個事件，就無法完成任務。
時間上的約束還意味著需要確定性。設計師依靠軟件元素，在已知或者有限的時間內完成各自的任務，本身沒有時間限制的任務（如等待循環）在執行時間攸關的任務時，能夠暫停掛起。
嵌入式開發的空間約束來自對成本和便攜性的需求。設計師需要盡量少用內存，往往使得設計受微控制器的片上內存資源的制約。但這也有助于降低功耗，這是電池供電的便攜系統所考慮的一個重要因素。
在這些時間和空間的約束下Java很難正常工作。Java軟件環境要與操作系統協同工作，并使用Java虛擬機把Java字節碼轉換成系統處理器的本機語言。它還需要相當大的類庫，作為核心系統的一部分。這兩種因素大大增加了對系統內存的需求。
Java的解釋碼運行起來本身就不如編譯碼快，這樣一來，系統更難滿足實時約束條件了。速度更快的處理器或許能幫上忙，但功耗因素往往使得嵌入式系統無法使用更快的處理器。就算系統足夠快，Java的垃圾收集算法也沒有時間限制、不可中斷，就不可能獲得確定性。
J2ME定義兩類Java
對于Java在嵌入式開發中遇到的問題，J2ME可以解決其中的一部分。辦法是縮減類庫大小，并且改變垃圾收集算法。J2ME定義了兩類Java：連接設備配置（CDC）和連接有限設備配置（CLDC），讓Java得以適用于諸多嵌入式系統，如下表所示。這些Java取代了較舊的嵌入式Java，而舊版本實際上是用于定制應用的非標準版本的Java。
CDC是一種功能齊全的Java，面向配有網絡連接、32位處理器和供Java平臺使用的2MB內存的設備。這個版本的Java允許設備以類似桌面機的方式，下載及運行通用的小應用程序。PDA、家用電器和汽車導航系統就是適合的目標應用。
CLDC是一種精簡版的Java，面向運行時環境更加定制的應用。CLDC并不允許運行通用小應用程序，而是要求Java程序符合設備的約束條件。這樣一來，Java“編寫一次、到處運行”的優勢也就無從談起，不過它仍保留了Java編程的其他優點。CLDC及其K虛擬機需要160KB的內存和16MHz的16位處理器。
Sun利用這兩種配置，開發出了符合許多嵌入式系統設計空間約束的標準Java配置，Java社區制訂的實時Java規范使得實時和確定性問題迎刃而解。實時Java規范（RTSJ）V1.0提供了Java平臺的標準擴展部分，并且改動了垃圾收集算法，確保了Java提供許多嵌入式應用所需的確定性。
這就只剩下原始性能問題還沒有加以解決。解決辦法來自行業提高Java執行速度的一系列方法，包括使用優化的JVM、執行前先把Java代碼編譯成本機碼，使用及時（JIT）編程器以及使用硬件加速，每種方法各有優缺點。
與普通JVM相比，優化的JVM通常可以把執行速度提高2～2.5倍。不過，這種優化要針對特定處理器。提供優化的JVM的廠商可能還會提供優化的類庫和實時操作系統，能夠與JVM密切合作，進一步提高軟件性能。
不管有沒有經過優化，使用JVM仍需要解釋工作，這就限制了程序的執行速度。把Java代碼編譯成本機碼、然后再執行可以避免這種限制。這種情況下，Java成了類似C++的另一種高級語言，限制執行速度的因素完全取決于編譯器的代碼效率。問題在于，與其他高級語言一樣，必須在把代碼植入程序內存之前，先進行這種編譯，結果導致系統缺乏靈活性，無法下載升級的Java代碼或者是新的應用程序。
及時編譯器力求通過“高速”編譯Java代碼以便可以立即執行，重新獲得這種靈活性。這帶來了高性能和靈活性，但也增加了特定應用程序的啟動時間，因為需要先開始編譯。由于至少占用100KB的內存（加上JVM和應用程序所需內存），使用及時編譯器還加大了對系統內存的需求。
硬件加速Java
為了加快Java執行，又避開編譯或者軟件JVM的缺點，嵌入式開發人員可以求助于硬件加速器。這種設備把JVM的部分或者全部任務轉交給專用硬件去處理，因而性能比解釋的Java提高了5～10倍。不過，硬件加速器并不接管所有任務，主機CPU仍處理特別復雜或者很少使用的字節碼。
半導體廠商采用了幾種方法，通過硬件來加快Java的執行速度，致力于不同任務。
一種是使用硬件解釋器。該解釋器把進來的Java代碼的大部分轉化成本機碼，從而給JVM省去了麻煩。例如Nazomi的Jstar、InSilicon的JVX和ARM的Jazelle。大多數情況下，解釋器擁有硅知識產權，這實際上擴大了處理器的指令集。
另一種方法就是使用協處理器。協處理器不僅解釋字節碼，還執行由此生成的機器碼，讓CPU完全得到解放。協處理器實際上是一種處理器，使用Java字節碼作為本機機器語言。有些協處理器如InSilicon公司的JVXtreme是純粹的協處理器，而有些協處理器如Aurora VLSI公司的Espresso和DeCaf可以充當協處理器或者獨立處理器，這樣在另一個CPU處理用戶界面等事務時，可以處理Java代碼。Ajile公司的aJ-100、DCT公司的Lightfoot和Zucotto公司的Xpresso都是協處理器。與解釋器一樣，這些協處理器往往作為用于ASIC或者FPGA實現的核心。
第三種方式是利用硬件及時編譯器高速編譯Java字節碼。這種設備有別于硬件解釋器，它不僅僅把軟件從一種形式轉換成另一種形式，實際上還能夠編譯，包括進行優化、重新安排代碼執行次序等。Parthus公司的MachStream就屬于這一類。
有了這一系列加快Java代碼執行速度的軟硬件方案，嵌入式系統的Java性能問題似乎可以得到解決了。遺憾的是，很難預測它們會給性能帶來多大幅度的提升。加速器與其他系統單元的相互關系更是加大了預測難度。CPU架構、可用系統內存的數量、實時操作系統（RTOS）、JVM、類庫和硬件加速都可能影響系統的最終性能，甚至應用軟件也會對性能產生影響。例如適用于Internet設備的系統軟硬件配置在機頂盒里面運行起來可能會比較慢，在移動電話上就完全不適合。
遺憾的是，嵌入式設計師沒有多少工具可以幫助自己測試非傳統配置的性能。最有用的工具就是系統性能測試公司開發的SPEC JVM98基準測試。但SPEC JVM98不是為了滿足嵌入式系統的測試需求，而是為聯網和獨立的客戶機開發的，并且前提是假設完全實現了Java，并擁有完整的桌面系統環境，而很少有嵌入式系統擁有這么豐富的資源。
Pendragon軟件公司的CaffeineMark這個基準測試在嵌入式領域頗為流行。與Dhrystone MIPS基準測試一樣,CaffeineMark也是一種人工基準測試，僅僅測試幾項Java特性，不包括浮點運算、垃圾收集和多線程這些項目，而對這些嵌入式開發人員來說可能很重要。另外，沒有標準配置可供基準測試來運行。因而，不同廠商的基準測試結果很難解讀。
對嵌入式Java而言，缺少測試工具問題也許不會長期存在。EDN嵌入式微處理器基準測試協會(EEMBC）已開始開發Java基準測試套件。EEMBC基準測試準備采用諸多系統測試指標，包括垃圾收集時間和確定性、I/O性能、中斷時延、內存使用以及測試過程中的系統功耗。還會包括詳細的軟件執行基準測試，測試項目包括類加載時間、類方法執行、所用線程數量、每個線程所用時間、以及調用線程的時間。該協會計劃在眾多應用環境下進行基準測試，包括智能卡、移動電話、掌上設備、Internet設備和機頂盒。
一旦這些工具準備到位，就可以根據預期應用來進行比較，從而大大方便了開發人員選擇嵌入式Java的諸多方案、確保系統的最終性能能夠達到預期。那樣，Java可以在將來的嵌入式系統開發當中扮演主角。