什么是J2ME及其基本慨念

<script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script> 如果您曾经http://www.javasoft.com ;网站上查询有关Java 2 Micro Edition 的资料，十之八九会被一大堆的技术名词搞的一头雾水。什么 KVM ，什么CLDC 、CDC 、MIDP ，后面面还冒出了Personal Java 、Embedded Java以及JES 等名词。虽然名为Java 的微小版本，可是它的世界可真是不小，让我们满肚子“见山不是山，见水不是水”的疑惑。的确，在我刚开始接触 Java 2 Micro Edition 的时候，就感觉到这个玩意儿实在越看越让人摸不著头绪。因此在本章中，我舍弃了技术上的细节，希望带大家从宏观的角度来看待 Java 2 Micro Edition 的世界。希望读过本文之后，可以使大家体验“见山是山，见水是水”，一切豁然开朗的感觉。首先，我们必须先对Java 2 Micro Edition 在整个Java 技术之中的定位做个了解。　 　 　　各种不同版本之Java 程序的开发 　 　　如前面所说，各种不同的Java 版本，在其支援的核心类别函式库之完整性以及所支援的 Java 基本型别这两件事情上都有所差异，也就是说，不管您开发的是企业所使用的Java 程序、嵌入式装置上执行的Java 程序、浏览器上执行的Applet ，或是在PC 上执行的应用程序。您都必须在您的电脑上先安装 J2SE ，然後再安装各种版本的核心类别函式库以及额外的扩充类别函式库，如此才能成功地开发各种不同目的的Java 程序。J2SE所提供的Java 编译器(javac.exe)可以帮助我们编译各种不同平台上的Java 程序，而J2SE 所提供的Java 虚拟机器(java.exe)则可以帮助我们在PC 上先行测试这些程序执行结果的正确与否。另外，Java 编译器并不会帮您检查您的程序是否符合各种平台上所支援的核心类别函式库与 Java 基本型别。举例来说，虽然我们在前面说过，Smart Card 版本并不支援boolean 、byte 以外的Java 基本型别，而且该平台也只支援java.lang.* 核心类别，可是当我们在撰写 Smart Card 平台上的程序时，就算在程序码里用了boolean 或byte 以外的Java 基本型别，或者使用了java.lang.*之外的其他核心类别，编译器仍然可以照常帮您编译出类别档。这个时候大家一定开始产生疑惑 --那么这些程序如果放到Smart Card 上头执行的时候，出了问题怎么办 ? 难道不会造成Smart Card 上的虚拟机器执行时发生错误吗 ? 针对这个可能发生的潜在问题，Sun Microsystems 在各种不同版本的开发套件中，有些会内附检查器 (checker)或者预先审核器 preverifier)，这两个工具可以帮助您在将程序放到目标平台之前先做好检查和预先审核的工作。检查器会帮您找出类别档之中不合目标平台规格的部分，并提醒你这些地方可能无法在目标平台上执行。因此只要有检查器的协助，您大致上可以确定您的程序可以符合目标平台的规定并顺利执行。 Java Card 的开发套件中就附有检查器。 　 　　而某些平台的开发套件则附有预先审核器，预先审核器除了做检查器做的工作之外，还有一项额外的工作，就是减轻目标平台上虚拟机器的负担，要解释预先审核器这个额外的工作，在传统的 Java 程序之中，为了安全上的考量，任何进入执行环境的类别档 (不管该类别档是来自本机或是远端机器 )，都必须先经过Byte Code 审核器(Byte code verifier)的验证，以防止程序在传送途中遭到恶意的修改，而使得 Java 程序在执行时对系统有不良影响。经过审核之後，该类别档才能开始被J 虚拟机器所执行。如果这个审核的动作在一般的 PC 上执行，速度倒是还能够接受，可是一旦放到如 Palm 或是手机这些CPU 较慢、记忆体也比较少的机器上面就显得十分吃力了。为了节省宝贵的 CPU 运算时间(既能省电又能够加速程序执行 )，因此，在程序设计师产生能够让某些特定平台执行的类别档之前，程序设计师必须先在 PC 上使用预先审核器做一些前置的审核工作，预先审核器会在类别档之中加入一些特殊标记或符号。如此一来，当这些程序放到目标平台上执行时，就可以大幅减少在目标平台上做审核时的时间，藉而加速程序的的启动及执行速度。因此在J2ME 之下的程序(Spotlet 、MIDlet)，其执行步骤变成因为预先审核的关系，执行时Byte Code，审核器的工作就变少了，也因此从程序载入到开始执行之间的时间因而缩短。 CLDC标准实作和MIDP 参考实作之中就附有预先审核器。 　 　　Java 版本的演进 　 　　相信熟悉Java 演进历史的人或多或少都听说过，Java 技术一开始并非就叫做 Java ，而是叫做OAK ，而且最早的时候就是为了嵌入式系统而设计的一项产品。後来因为网际网路的发达，而OAK 的诸多特性刚好又适合用在网路上(例如可移植性、编译後程序码很小)，因为商标已被注册的关系，因此 OAK 被改名成Java ，从此因缘际会地成了网路上的闪亮巨星，并随著时间越来越成熟，也慢慢地产生了许多非原本预期中的相关运用。 　　虽然 Java 已经被用到许多企业级软体上，可是其实骨子里面还是非常适合用在嵌入式系统之中。　 　 　　虽然从Java 1.0 发表之後，Java 就被广泛地使用在桌上型应用程序以及Applet 的开发上，但是，从Java 1.1 开始，Java又回到了它一开始的老路--也就是嵌入式系统方面的应用，在当时Sun Microsystems 发表了Embedded Java 与Personal Java(也有人简称为PJava)这两项规格。其中Embedded Java 是为了资源十分有限，而且没有显示设备的嵌入式装置而设计；　Personal Java 则是为了在能够与网际网路连线、并拥有显示系统(例如彩色LCD)的消费性电子装置而设计。接著Java 的版本演进到Java 2 ，这时为了再明显区分各种Java 的应用，所以分割出了J2EE、J2SE、以及 J2ME 三种版本。这三种版本的各种特性我们已经在前面已经详细地描述，在此不再赘述。不过请大家记住，由於 Java 2将Java 的应用区分成三大块，使得 Java 程序语言的发展不会再像Java 1.1时如树枝状般扩散出去，这么一来有助于大家对 Java 各种应用的了解，而不会造成今后越发展下去越不可收拾的混乱局面。额外向大家一提的是，后来Personal Java 发展到1.2 版的时候，也采用了一些Java 2 平台上与安全性有关的设计。　 Java 2 Micro Edition 概念 　 　　J2ME 在设计其规格的时候，遵循著「对於各种不同的装置而造出一个单一的开发系统是没有意义的事」这个基本原则。於是 J2ME 先将所有的嵌入式装置大体上区分为两种 :一种是运算功能有限、电力供应也有限的嵌入式装置(比方说PDA 、手机)；另外一种则是运算能力相对较佳、并请在电力供应上相对比较充足的嵌入式装置 (比方说冷气机、电冰箱、电视机上盒 (set-top box))。因为这两种型态的嵌入式装置，所以Java 引入了一个叫做Configuration 的概念，然後把上述运算功能有限、电力有限的嵌入式装置定义在Connected Limited Device Configuration(CLDC)规格之中；而另外一种装置则规范为 Connected Device Configuration(CDC)规格。也就是说， J2ME 先把所有的嵌入式装置利用Configuration 的概念区隔成两种抽象的型态。　 　 　　其实在这里大家可以把Configuration 当作是J2ME 对於两种类型嵌入式装置的规格，而这些规格之中定义了这些装置至少要符合的运算能力、供电能力、记忆体大小等规范，同时也定了一组在这些装置上执行的 Java 程序所能使用的类别函式库、这些规范之中所定义的类别函式库为 Java 标准核心类别函式库的子集合以及与该型态装置特性相符的扩充类别函式库。比方就CLDC 的规范来说，可以支援的核心类别函式库为java.lang.* 、java.io.*、java.util.*，而支援的扩充类别函式库为java.microedition.io.*。区分出两种主要的Configuration 之後，J2ME 接著在定义出Profile的概念。Profile 是架构在Configuration 之上的规格。之所以有Profile的概念，是为了要更明确地区分出各种嵌入式装置上Java 程序该如何开发以及它们应该具有哪些功能。因此Profile 之中定义了与特定嵌入式装置非常相关的扩充类别函式库，而 Java 程序在各种嵌入式装置上的使用者介面该如何呈现就是定义在Profile 里头。Profile 之中所定义的扩充类别函式库是根据底层Configuration 内所定义的核心类别函式库所建立。　 　 　　Java 在嵌入式系统上的应用 　 　　由于Java 本身最初的设计理念即是针对嵌入式系统，因此将他用在嵌入式系统上真可谓如鱼得水。在这个Linux 开始兴起的时空交会点，网路上出现了一篇关于嵌入式 Linux 与Java 互相配合以造就双赢局面的相关报导，这是由 LinuxDevices.com 的专栏作家 Randy Rorden 所发表的一篇白皮书，名为「 Java 与嵌入式 Linux 合作」。 在这篇文章里头，作者对嵌入式Linux与Java 个别的优点提出他的看法，同时也提出了Java-Linux 平台的构想。有兴趣的读者可以到到下列几个网站参考相关新闻与资料。　 　 　　1. Java 与嵌入式 Linux 合作白皮书 　　　 http://www.ctech.com.tw/d-news/news/linux/89090208.asp ; 　　2. Java 及嵌入式Linux 合作 　　　 http://www.linuxdevices.com/news/NS5973673868.html ; 　　3. 即将来临的Java-Linux 结合 　　　 http://www.linuxdevices.com/articles/AT7102892618.html ; 　 　　为何要用Java 撰写PDA 上的应用程序? 　 　　由於预期到今後行动通讯时代的来临，所以通讯相关行业变的前景可期，而除了达成行动通讯的主要工具 -- 手机月来越精巧之外，有更多的厂商相继投入PDA 的生产与开发。本来PDA 主要的平台有PalmOS 、Windows CE 以及EPOC ，也不知道曾几何时，开始一大堆公司投入embedded linux 的研发，其中包括国内资策会自己开发的 @ViS 作业系统，互慧科技也有自己的嵌入式作业系统，当然更不用说大陆厂商与韩国厂商了。 　　这些作业平台的数量比起 PC 来说真不知道要复杂上几倍。对一般使用者来说当然影响比较小，可是对於程序开发者来说，看到这么多不同的程序发展平台，真是让人望之却步。如果每个平台都有自己的程序写法以及函式库，那么光是看上面这些平台至少就要学习五种以上程序的写法。当然，只专精一种平台当然是很好的事情。可是程序设计师不禁要说 :”如果我们写出来的软体可以在不经过修改原始码的情况下就能够在这些平台上执行，那不是更完美吗?” 对程序开发者来说，这样的投资报酬率当然是最大的。　 　 　　要在那么多平台上开发程序，对程序设计师来说的确是一个很大的挑战，如果要把所有的时间和精力放在软体的可用性上，那么相对地很多时候我们根本没有那么多时间撰写各种平台的程序。要解决这个问题，一般来说程序设计师会选用一个可以跨平台的Framework 来达成至少source code level 的跨平台(例入Qt 就能做到)。不过在本篇文章中我们要介绍的则是更终极的解决方案 ?Java ，利用Java 的”write once, run anywhere”特性，我们可以真正达到程序只要写一次，拿到任何平台上都可以执行(当然前提是必须要PDA 的厂商也要实作出该平台的Java Virtual Machine 才行)。利用Java 来做PDA 上的程序当然有其缺点，最广为人知的可能就是执行效率的问题， Java 在执行速度这个议题上一直让人诟病。 　　不过笔者认为，随著技术的发达，将会有更快更省电的PDA 专用CPU 出现，因此效率上的问题其实是可以忽略的。更何况，当 Sun 在设计J2ME 的时候，也用了很多方式企图加快Java 在PDA 上的执行速度(例如预先审核)。