J2ME中文教程 2 CLDC简介

本章将介绍J2ME的核心部分——有限连接设备配置，即Connected，Limited Device Configuration（CLDC）。CLDC提供了一套标准的、面对小型设备的Java应用开发平台。

设备的配置configuration是指针对某一类设备的最小的Java平台。其中包括满足该类设备的虚拟机运行的最小子集和针对该类设备的核心类库的最小子集。有限连接设备配置就是为有限连接设备定义了一个基本的J2ME运行环境。

本章讲述的内容如无特殊说明，均以CLDC1.0的规范为基准。

本章将从以下几个方面来介绍CLDC：

1) CLDC概念

2) CLDC功能

3) CLDC的安全机制

4) CLDC的类库

5) CLDC1.1与CLDC1.0的区别

2.1 CLDC概述

2000年5月，Java Community Process（JCP）公布了CLDC1.0规范（即JSR30）。作为第一个面对小型设备的Java应用开发规范，CLDC是由包括Nokia，Motorola和Siemens在内的18家全球知名公司共同协商完成的。CLDC是J2ME核心配置中的一个，可以支持一个或多个profile。其目标主要面向小型的、网络连接速度慢、能源有限（主要是电池供电）且资源有限的设备，如手机、机顶盒、PDA等。CLDC1.0的规范可以在jcp的网站上下载：http://www.jcp.org/en/jsr/detail?id=30。

CLDC标准构架

CLDC的核心是虚拟机和核心类库。虚拟机运行在目标操作系统之上，对下层的硬件提供必要的兼容和支持；核心类库提供操作系统所需的最小的软件需求。

2.1.1 CLDC的目标

1) 为小型的、资源受限的连接设备定义一个Java平台标准

2) 允许向上述设备动态的传递Java应用和内容

3) 使Java开发人员能够轻松的在这些设备上进行应用开发

2.1.2 CLDC的整体需求

1) 能运行在绝大多数的小型的、资源受限的连接设备上

2) 用CLDC为上述设备开发的应用尽可能的不使用设备的本地系统软件（做到与平台、设备无关）

3) 定义能应用在绝大多数上述设备上的最小子集的规范

4) 保证在不同类型上述设备之间代码级的可移植性和互操作性

2.1.3 CLDC的硬件需求

由于CLDC要面向尽可能多的设备，而这些设备所使用的硬件又各不相同。因此CLDC规范中并没有指明需要某种硬件支持，只是对设备的最小内存进行了限制。CLDC规范中要求硬件必须达到以下要求：

1) 至少160KB的固定内存以供虚拟机和CLDC核心类库使用。

2) 至少32KB的动态内存以供虚拟机运行时使用（堆栈等）。

这里所说的固定内存是指拥有写保护，不会因关机而抹去的ROM。对于具体的设备的具体实现，这些需求也可能有变化。这里所规定的160KB是CLDC规范中的要求，实际也可以是128KB左右。

2.1.4 CLDC的软件需求

和硬件类似，CLDC上运行的软件也是多种多样的。例如，有些设备支持多进程操作系统或者支持文件系统；而有些功能极其有限的设备并不需要文件系统。对于这些不确定性，CLDC只定义了软件所必须的最小集合。CLDC规范中要求操作系统不需要支持多进程或是分址空间寻址，也不用考虑运行时的协调和延迟；但是必须提供至少一个可控制的实体来运行虚拟机。

2.2 CLDC的功能范围

2.2.1 CLDC包含的功能

在CLDC1.0版本中定义了以下功能：

1）Java核心语言与Java虚拟机的特性

2）核心Java类库

3）输入/输出

4）对网络的支持

5）对安全性的支持

6）对国际化的支持

2.2.2 CLDC不包含的功能

1）对应用程序生命周期的管理

2）用户界面

3）事件处理

4）高级应用程序模式（这里指用户与应用程序的交互）

2.2.3 CLDC与J2SE的关系

CLDC包含了一个基本的J2ME运行环境，其中包括虚拟机和核心的java类库。作为专门针对于小型设备的配置，CLDC对J2SE类库进行了大量的简化，其类库只保留了java 规范中定义的最核心的3个包，即java.iojava.lang和java.util，并重新定义了一个新的包javax.microedition。这里你可以通过前缀来区别：java.表示核心的java包，javax.表示标准java扩展包。

这里要注意的是在CLDC中定义的javax.microedition包为javax.microedition.io，用来支持通用连接框架（GCF，Generic connection framework）。CLDC中的包和所对应的功能如下所示：

1) CLDC包	2) 对应的功能
1) java.io	2) 标准的输入/输出功能，J2SE java.io包的子集
3) java.lang	4) 核心语言包，J2SE的子集
5) java.util	6) 实用类
7) javax.microedition.io	8) 通用连接框架类及接口

CLDC中的包和所对应的功能

javax.microedition中其他的包定义了CLDC中没有定义的功能，如对应用程序生命周期的管理、用户界面（UI）、事件处理模式、永久性存储和用户与应用程序的交互等。这些功能的定义是由Profile （即MIDP）来完成的。

2.2.4 CLDC核心类库与J2SE的主要区别

由于CLDC主要针对16位、32位主频在16MHz以上的处理器，设备内存只有512KB，甚至更少，而目前Windows平台下运行的JVM需要的最小内存为16M。因此CLDC所使用的虚拟机和核心类库与J2SE的并不相同。

1．不支持浮点数据类型（没有float和double）

因为很多使用CLDC的设备硬件都不支持浮点运算，而且处理浮点运算需要较大的内存。因此在CLDC1.0中，并没有要求虚拟机支持浮点数据类型。

9) dadd	10) dmul	11) fadd	12) fmul	13) i2d
14) dalaod	15) dneg	16) faload	17) fneg	18) i2f
19) dastore	20) drem	21) fastore	22) frem	23) l2d
24) dcmpg	25) dreturn	26) fcmpg	27) freturn	28) l2f
29) dcmpl	30) dstore	31) fcmpl	32) fstore	33) newarray(double)
34) dconst_0	35) dstore_x	36) fconst_0	37) fstore_x	38) newarray(float)
39) dconst_1	40) dsub	41) fconst_1	42) fsub	43)
44) ddiv	45) d2f	46) fdiv	47) f2f	48)
49) dload	50) d2i	51) fload	52) f2i	53)
54) dload_x	55) d2l	56) fload_x	57) f2l	58)

CLDC不支持的浮点数据类型

对于CLDC的应用，Sun使用了和J2SE相同的编译器，这使得使用浮点数据的类及对象在编译的时候可以正常通过。因此Sun引入了类审核机制来阻止未经定义的类调入虚拟机。

2．不支持JNI (the Java Native Interface )

CLDC不提供native code的支持，除了因为设备内存有限外，还出于安全性的考虑。因为CLDC中缺少完整的安全性模型，禁用了这些J2SE的特性可以使潜在的安全风险降到最低。

3．不支持以及用户自定义的Java级的类载入器（class loaders)

CLDC不允许用户自定义类载入器。按照CLDC规范的要求，类的载入是不能被覆盖、替换和修改的。和JNI类似，这些是出于安全方面的一些考虑。

4．不支持反射(reflection)

不支持java.lang.reflect包以及java.lang.Class中和reflection有关的函数。其目的主要是节省内存占用。

5．不支持线程组（thread groups）或守护线程（daemon threads）

CLDC提供了对线程的支持，也支持多线程，但是线程组和守护线程是不被允许的。每个线程都要生成独立的Thread对象来实现。如果应用程序想实现对一组线程的操作，则必须在应用程序的级别上自行实现多个Thread对象的控制，如使用Hashtable和Vector来存取多个Thread对象。

6．不支持类实例（class instance）的终结（finalization）

CLDC类库不包含java.lang.Object.finalize()方法，因此类对象的终结是不支持的。对于应用CLDC的设备来说，对象终结相对于它所起的作用来说实现起来过于复杂，并不被需要。

7．不支持弱引用（weak references）

8．有限的错误处理（error handling）

在J2SE中定义了大量的类用来描述各种错误和异常，而CLDC仅仅包含有限的几个J2SE的核心类库，因此大部分java.lang.Error的子类都未被支持，这包括异步异常。这是因为在嵌入式系统中，应用程序并不期望获得设备的出错处理机制；定义和运行出错处理需要较大的虚拟机的开销，而这些出错的代码信息对于连用户界面都没有的有限连接设备来说是没有用处的。

2.3 CLDC的安全机制

2.3.1 CLDC的安全级别

在CLDC中，虚拟机不允许用户安装程序，因此安全特性和J2SE比要少很多。CLDC规范中主要定义了以下3个级别的安全机制：

1，底层安全机制（low-level security）

底层安全就是通常说的虚拟机的安全，是虚拟机运行在CLDC设备上的最关键的安全机制。它要求运行在虚拟机上的应用程序必须遵循Java语言的标准语法，且能够检查出并组织恶意代码（类）以各种方式对设备进行破坏。对于标准的Java虚拟机的实现，虚拟机使用类审核的方式来保证虚拟机安全。类审核机制能够确保类文件中的字节码以及其他对象不包含非法指令，不会以非法的顺序被执行，也不会访问虚拟机以外的非法内存地址或是地址段。

在CLDC中，类的审核机制不同于J2SE，它增加了预审核（pre-verification）机制。2.3.1节将对CLDC的预审核机制做详细的说明。

2，应用级别安全机制（application-level security）

仅用类审核机制来保证Java平台的安全运行是不够的。因为它仅仅能够确保应用程序的代码是可用的，还有很多潜在的安全威胁没有被涉及到，如对文件系统、打印设备、红外、本地类库以及网络等安全管理。在应用级别安全机制中，CLDC规定，Java应用程序只能访问系统类库、系统资源、额外的设备元件（如即插即用的设备等）和Java运行环境。

具体的实现是：应用程序运行在一个封闭的沙箱（sandbox）环境中以得到保护。在沙箱中，只有系统已定义的配置（configuration）、简表（profile）、可选包以及设备支持的一些类可以被应用程序访问。任何没有预先定义类库和资源都不允许访问，以防程序中的恶意代码对沙箱外的资源（如操作系统、硬盘等）非法访问或者破坏。

沙箱的需求主要有：

l 类文件必须经过审核且是可用的Java程序。

l 应用程序的下载、安装和管理等操作都不能修改、覆盖或着绕过类虚拟机实现的标准的加载机制。

l 只有预先定义好的，封闭的Java API和类可以被应用程序调用。这包括配置、简表、可选包以及该应用自定义的类。

l 任何没有被CLDC定义的native code都不允许调用。这意味着应用程序不能下载一个新的含有native code的类库并使用。

l CLDC规范额外规定了系统类和应用程序类的命名规则。也就是说，为了满足上面说的沙箱的要求，所有java.*和java.microedition.*都属于系统类，不能被覆盖，修改；也不能任意增减。应用程序类不能使用上述包名来实现自己的类。

l 而且，除了调用系统类之外，应用程序只能调用自身JAR包中的类。这样保证了应用程序不能从其他的应用程序中“偷”数据(或类的实现)来达到自身的目的。

注：在最新的JSR246（Device Management）中，通过设备管理框架（Device Management Framework），满足一定条件的应用程序有可能访问其他应用程序的数据，但是对绝大多数应用程序来说，别人的数据仍然是不可以访问的。（想用楷体，但是机器上没有除宋体以外的其他字体……哭）

3，端对端的安全机制（end-to-end security）

端对端的安全机制主要指在数据传输时的安全，如数字签名、加密等机制。考虑到网络不是CLDC设备必须支持的功能，这方面的定义是由上层相应的简表来完成的，如MIDP；CLDC规范中并没有详细的规定。

2.3.2 CLDC中类的预审核模式

J2SE提供了字节码的审核机制用于检查类文件的完整性。该审核机制是在编译时进行的，其目的是确保类文件中不包含可能破坏系统安全的或是违反了Java语言规范的恶意代码。其内容主要包括：

1）所有本地变量在使用前必须初始化

2）在构造对象时，其构造函数必须在该对象被使用前调用

3）每个对象的构造方法都必须调用父类的构造方法（要求最先调用java.lang.Object的构造方法）

4）本地变量、实例和静态成员在声明时指明的对象类型必须和实际赋值的对象类型一致。例如，给一个声明成String类型的变量赋予Integer类型的值是不被允许的。

类的审核机制仅仅针对于外来的类文件（比如从网络上下载的），而对本地文件系统中的类的加载是不用审核的。

CLDC和J2SE一样，也要求虚拟机能够辨别并拒绝非法的类文件。但由于J2SE中定义的标准类审核过程对于应用CLDC的小内存消耗的小型设备来说是不现实的，因此CLDC专门定义了其特有的预审核机制。

在CLDC的预审核机制中，要下载的Java类文件的每一个方法都包含了一个堆栈映射属性，这个属性是CLDC独有的，J2SE规范中没有定义。堆栈映射的属性会通过虚拟机的预审核器添加到标准的类文件中，该预审核器会分析类中的每一个方法。堆栈映射属性通常会增加约5％的类的大小。

预审核机制

如图所示，当程序的源程序被编译后，必须被预审核器预审核，然后才能生成可以被下载到目标设备上运行的类文件。把一部分的审核任务放在预审核器中完成，可以使与CLDC兼容的虚拟机审核Java类文件时速度更快，并且只需要很少的虚拟机代码和动态内存，而它们的安全级别相同。因此，在CLDC/MIDP环境下开发程序，其程序经过编译后，必须经过预审核后才能运行。

特别需要说明的是：

1. 经过预审核器审核过的Java类文件不需要修改就可以直接运行在J2SE和J2EE环境上，这使得移植和相互调用变得非常简单。

2. 运行时的审核机制CLDC把它交给了设备自己去实现。设备可以根据自身的需要在加载类或是安装应用程序的过程中执行。在运行时，虚拟机迅速地对字节码进行线性扫描，将每个有效的指令与合适的堆栈映射项相匹配。运行时的审核过程是建立在预审核机制之上的，所以比预审核还要快，占用的动态内存更少。

2.3.3 CLDC中的类的文件格式

CLDC要求所有第三方开发的支持CLDC的Java应用程序在公开发布时都要使用JAR包的格式，而且JAR包内的类必须是经过了预审核器审核之后的。同样的，CLDC要求所有实现CLDC的虚拟机也必须能够识别和调用JAR包中的文件。

2.4 CLDC的类库

CLDC标准为了能够涵盖尽可能多的设备，其类库只包含了最小的Java平台特性和API。面对严格的内存限制和当前各种各样的小型设备，CLDC不可能覆盖全部的这些设备。因此在CLDC的规范中，不可避免的会造成对某些设备要求过高或是对另一些设备要求又太低的现象。

为了确保与其他Java平台的兼容性，绝大多数的CLDC类库是从J2SE和J2EE中继承的，是J2SE和J2EE的子集。由于目标设备的特殊性，CLDC类库在安全、输入/输出、用户界面、网络和存储管理等方面没有全部使用J2SE的实现；其中的部分类库CLDC进行了重写，如网络连接。

如2.2.3中所介绍的，CLDC的类库可以分为两种：一种是从J2SE标准类库中继承的；另一种是专门为CLDC设计的（这部分类也可以被映射到J2SE中）。

对于第一种CLDC类库，包括了J2SE的3个最核心的包java.io、java.lang和java.util。而且这3个包和J2SE相比，也只是J2SE相应包的一个很小的子集。例如java.util的类与接口由J2SE中的53个减少到10个。

对于后一种CLDC类库，只有描述标准连接框架的javax.microedition.io包，和MIDP中定义的包一起放于javax.microedition包中。

2.4.1 java.lang包

java.lang包包含了Java语言API的核心部分继承下来的类，但是CLDC只继承了J2SE中一半的类，而且一些类中的接口并没有完全实现。这主要表现在：

1）绝大部分的虚拟机不支持错误类和部分异常类被去掉了。

2）不支持Float和Double数据类型及其相应的类

3）ClassLoader、SecurityManager等CLDC规范上没有说明必须支持的类也不在此包中。

下表给出了CLDC 的java.lang包中的类及类的继承关系。

CLDC1.0 java.lang包中的类及类的继承关系

java.lang.Object类：

Object类中需要注意的有以下两点：

1. 没有finalize( )方法。

2. 没有接口类java.lang.Cloneable，<spa