Java本來就是為了嵌入式系統而生
1990年12月，Sun內部由James Gosling、Patrick Naughton以及Mike Sheridan成立了一個叫做Green Team的小組。Green Team小組的主要目標，是要發展一種新架構，而這種架構必須能夠在消費性電子產品作業平臺上運行，現在我們普遍認識的PDA、手機或是信息家電(IA)，都是屬于這種架構的目標平臺。接著，Green Team在1992年的9月3號，發表了一款由Java 技術之父 James Gosling所領軍研發，名叫Star Seven(*7)的機器，研發出一部交互式的掌上型家用娛樂裝置，可透過使用動畫觸碰式屏幕的使用者接口來控制其它電子設備。
經過了13年的時間，現在我們檢視J2ME的發展歷史，我們可以發現，雖然在1999年，Java被切割成J2SE、J2ME、J2EE，所以有了J2ME這個名詞的出現。但是Java并非1999年開始才開始發展嵌入式系統上的應用。其實，Java本來就是為了嵌入式系統而發展的一種架構。即使目前大家多半將Java的應用聚焦于企業上的J2EE應用。但是嚴格來說，J2ME才是Java真正“回歸本心”的領域。
半路殺出的Personal Java
Personal Java是正規Java版本的一個分支，其目的在于能夠讓PDA或高階手機執行Java程序，目前在Windows Mobile或Symbian OS(僅限采用UIQ或Nokia Series 80的行動電話)平臺上都可以開發Personal Java應用程序。
雖然從Java 1.0發表之后，Java就被廣泛地使用在桌上型應用程序以及Applet的開發上，但是，從Java 1.1開始，Java又回到了它一開始的老路-也就是嵌入式系統方面的應用，在當時Sun Microsystems發表了Embedded Java與Personal Java（也有人簡稱為PJava）這兩項規格。Personal Java的規格是從Java 1.1之中所分支出來，因此Personal Java的規格是根據Java 1.1的規格而制定的，但是并非Java 1.1的全部規格都包含進來，所以Personal Java只能算是Java 1.1平臺的子集合。
Personal Java特別適合用在具有豐富圖形顯示能力的消費性電子產品上面，于是我們可以發現Sun Microsystems網站上對于Personal Java的參考實作是建立在Windows Mobile產品(過去叫做Pocket PC)上頭的。
在1999年，一般PDA或手機的能力，離Personal Java所需要的硬件條件仍有很大的一段差距，因此Personal Java并不是一個很成功的產品。因此Sun Microsystems在此時將Java區分成J2SE、J2EE、J2ME這三塊，希望可以重新塑造整個架構，尤其是J2ME，希望Java可以在嵌入式系統的領域有所發展。
J2ME從何而來?
談到J2ME，大家就會聯想到KVM這個名詞， KVM的設計者Antero Taivalsaari，最早在Sun Microsystems參與Spotless Project，這個項目才是J2ME的最早起源。由于Antero Taivalsaari曾經在世界知名電信設備制造商工作，所以他有了在手機上開發JVM的概念，后來得到公司支持，就有了各位所知的KVM(K Virtual Machine)。
最早應用KVM的產品，就是一個可以在Palm OS上執行的KJava。KJava并不算是一個正式產品，只能算是一個概念測試產品。開發人員會開發名為Spotlet的應用程序，透過工具和KVM的輔助，應用程序就可以在PDA上執行。雖然KJava早已成為過去式，但是仍有電信廠商使用這個名詞，作為手機上Java平臺的名稱，不過，已經不是真正的KJava了。有了KJava的發展經驗，Sun著手設計J2ME的架構，讓J2ME可以應付未來嵌入式系統的發展。
J2ME整體架構
J2ME最基本的規范制定在JSR-68(Java規格編號第68號)，在此規格里頭定義了J2ME的技術架構。根據此規范，J2ME由三種類型的規范堆棧而成，分別是Configuration、Profile以及Optional Packages。這三種類型的規范定義由其它的規范所定義。
在最底層的Configuration規范，定義了硬件所必須具備的能力，比方說硬件至少具備多少ROM、RAM，CPU的頻率最少應該是多少，連接網絡時頻寬至少要多快。Configuration規格之中定義了一組低階的API，這代表Java至少必須提供的低階功能，這組低階的API就是核心類別函數庫的子集合。
在Configuration之上的規范稱為Profile。Profile針對各種不同機器的特性定義了高階的API，這些高階的API通常都是與其它平臺不相關的擴充類別函數庫。這些高階API決定了該種機器上Java程序的撰寫方法。比方說行動通訊裝置(手機、PDA等)這類型裝置上Java程序的撰寫方式，以及能夠調用的API，都定義在MIDP(Mobile Information Device Profile)之中。
就算是同類型的裝置，有些功能也不一定具備(有些廠商的機器可能有，有些廠商的機器可能沒有，例如手機上的照相機、和弦鈴聲等)，這些功能就定義在“廠商選擇性實現套件(Optional Package)”之中，比方說，有的廠商會提供簡單的數據庫管理系統(DBMS)在該裝置上，那么他們就會實現JDBC Optional Package。不提供數據庫管理系統的廠商就不需要實現JDBC Optional Package。所以稱作廠商選擇性實現套件。
所謂的廠商選擇性實現套件，意思是說，這是一組和其它規格(或API)沒有任何相依性的類別函數庫，如果廠商愿意提供這樣的功能給程序設計師(通常是因為硬件具有充分的能力可以完成規格之中所制定的功能)，就會將這組類別函數庫實現出來，程序設計師也可以利用這些功能開發出功能更多的應用程序。
MIDP工業標準
雖然J2ME架構完整，但是目前的發展，除了Personal Profile之外，最大的應用在于架構在CLDC之上的MIDP。目前所有標示可以支持Java的手機，所支持的都是MIDP，幾乎所有的無線通訊廠商皆采用MIDP作為其開發程序的標準。
在MIDP 1.0的時代，由于規格上本身的功能不足，使得許多廠商不得不加入自己專屬的API，例如震動、背光、聲音等擴充功能(例如:Nokia UI API)，以彌補MIDP平臺的不足。
到了MIDP 2.0，增加了許多眾所期盼的功能，但是，即使規格更清楚了，即使很多新功能都已經由JCP制定成標準的Optional Packages，這些問題依然無解。市面上的MIDP平臺仍然處于混亂狀態。開發者必須在執行時期偵測各種專屬API和Optional Package的存在，這會增加多余的程序代碼。平臺的混亂會造成在某個裝置上可以順利安裝及執行，而到了其它裝置時，有可能無法執行，甚至有可能連安裝都有問題，所以開發者通常要開發好幾種版本的MIDP應用程序供各種廠牌、各種型號的裝置使用。
為了解決上述問題，進一步提高MIDP應用程序的可移植性，Sun Microsystems以MIDP 2.0規格為核心，設計了JTWI規格。未來的無線通訊平臺，將不會只有符合MIDP 2.0規格，而是必須要符合JTWI規格。這將是J2ME軟件在可移植性上的一大突破。JTWI(Java Technology for Wireless Industry)是一個統合性的規格，其目的是為了確保MIDP軟件的可移植性。所以JTWI規格除了規范無線通訊平臺(特別是手機)所必須支持的J2ME標準之外，也對既有規格中模糊不清的地方與以加強。所以新款的手機為了加強移植性，都會支持JTWI標準。JTWI只是一個統合性的規范，并沒有制定任何新功能，目的只是要統一當前平臺混亂的現象，讓J2ME應用程序更具可移植性。JTWI主要分成幾個部分:
1 .規定平臺必須支持的API。
2 .統一的應用程序執行環境。
3 .既有規格的理清與加強。
在規定平臺必須支持的API的部分，JTWI規定至少必須支持CLDC 1.0、MIDP 2.0以及WMA 1.1:
所以，只要廠商宣稱支持JTWI平臺，那么代表一定支持CLDC 1.0、MIDP 2.0以及WMA 1.1規格之中的所有功能。另外，廠商可以根據裝置本身的能力，將CLDC 1.0提升成CLDC 1.1，可以加入MMAPI 1.1。因此實際上JTWI平臺會有一下幾種組合方式:
其中，CLDC 1.1 + MIDP 2.0 + WMA 1.1 + MMAPI 1.1是最完整、功能最強平臺。
在統一應用程序執行環境方面，過去讓J2ME應用程序開發者最為頭大的問題有以下幾項:
● 應用程序的大小可以多大?
● 執行時期的內存有多少可以使用?
● 有多少內存空間可以作為永久儲存之用?
由于規范中對于J2ME應用程序本身的大小和執行環境沒有很詳細地規范，使得每家廠商都有自己的規范，比方說Nokia限制應用程序最大只能30 KB，Motorola則可以支持50 KB以上的應用程序。這些規范都嚴重地困擾著開發人員。這些問題在JTWI之中都獲得改善。
JTWI定義了應用程序的標準大小(Standard-size Application)。JTWI規定，可以執行J2ME應用程序的行動通訊裝置，至少可以容許大小為64 KB以上的程序主體(JAR文件)、5 KB以上的應用程序描述文件(JAD文件)、以及30 KB以上的永續儲存空間、執行時期的內存(Heap Memory)為256 KB。上述大小只是底線，廠商可以視裝置的實際能力支持更大的內存空間。標準應用程序大小(Standard-size Application)將成為一個計算用的單位，舉例來說，廠商會說這個裝置可以安裝20個標準應用程序，開發者所撰寫的程序可以說這個程序需要占掉3個標準應用程序的空間。
至于對既有規格的理清與加強的部分，我們將在往后章節一一說明。最重要的一點是，JTWI規定，該裝置所支持的任何媒體格式(例如圖片、聲音、影像等)都應該能夠使用HTTP 1.1獲取，也就是說，存取這些媒體時所使用的URL都必須能夠接受http作為存取的通訊協議。