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作为存取的通讯协议。