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