cldc1.0是在2000年的10月份推出的，随后sun又发布了包括rms和ui等特性的midp1.0，这对业界的震动很大，很快就有开发者针对移动信息设备开发应用了。随着设备能力的提高在jsr118又推出了功能更为强大的midp2.0。但是从midp1.0的发展历程可以看到一些问题，由于cldc1.0+midp1.0的配合提供的api有限，所有各个厂商就开发了自己设备独有的api。同时为了针对各个设备不同的功能特性，j2me中提出了可选包的概念，比如bluetooth,pim等。这造成了api被分裂和可移植性降低的后果。
　　
　　由于设备没有一个统一的标准的软件运行环境，导致了api的分裂。开发者在针对某些机型进行开发之前还必须要查询这个设备到底支持什么功能，有哪些是标准的api，哪些是可选包和厂商提供的api。这无疑给开发带来了不便。
　　
　　由于没有一个统一的标准的针对设备的规范，这就使得程序的可移植性大大降低。如果你得程序中使用了nokia的api那么程序很难在其他厂商的机器上跑。即使你是用了标准的api，你得程序也不一定就能够移植，各个厂商对应用程序的大小限制不一样，有的是30k,有的是50k。对线程支持的程度也不一样，有的可以支持3个，有的是5个。
　　
　　java technology for wireless industry出现的目的则是为了解决如上两个问题，它是在jsr185中提出的。jtwi并没有提出新的技术，也没有提供新的api。它对j2me的运行环境作了规范，提供了一个标准的更加严格的运行环境，这有效的减小了api的分裂并提高了程序的可移植性。jtwi是以一下的规范为基础的
　　
　　jsr 30 cldc1.0 提供了基本的语言类库，但是不支持浮点运算。可以用cldc1.1替代1.0
　　
　　jsr118 midp2.0　提供了图形用户界面、持久性存储、game和多媒体等功能模块的支持
　　
　　jsr120 wma1.1　提供了短消息功能的支持
　　
　　另外mmapi1.0(jsr135)是jtwi中可选的部分。提供了对多媒体的全面支持，midp2.0中的多媒体部分是mmapi的子集。
　　
　　jsr185对如下的一些方面进行了规范，实现jtwi的设备必须遵守这些规范
　　
　　规定了标准应用程序的大小，设备必须支持64k大小的应用程序和5k的jad文件。持久性存储的大小为30kb,heap空间从midp2.0中的128kb提高到256kb
　　
　　记事功能，这样你可以使用pushregistry的registeralarm()方法
　　
　　jsr185对设备的屏幕尺寸作了建议125*125/12bits。设备必须支持jpeg格式的图片。http1.1必须被支持
　　
　　jsr185是基于wma的，因此设备必须具备短消息发送和接受的能力，jsr185还规定，应用程序在准备发送短消息的时候，当提供了textfield和textbox组件的时候，应该可以给用户弹出本机电话本可以选择
　　
　　对移动多媒体进行支持，必须实现对midi和单音的支持