BB开发中需要明白的一些概念性问题
CLDC简介
CLDC是由包括Nokia，Motorola和 Siemens在内的18 家全球知名公司共同协
CLDC
商完成的。CLDC是J2ME核心配置中的 一个，可以支持一个或多个profile。 CLDC 的核心是虚拟机和核心类 库。虚拟机运行在目标操作系统 之上，对下 层的硬件提供必要的兼容和支持；核心类库提供操作系统所需的最小的软件需求 。 2000年5月，Java Community Process（JCP ）公布 了CLDC1.0规范（即JSR30）。作为第一个面对小型设备的Java应用开发规范，CLDC是由包括Nokia，Motorola和Siemens 在内的18家全球知名公司共同协商完成的。CLDC是J2ME核心配置中的一个，可以支持一个或多个profile。其目标主要面向小型的、网络连接速度 慢、能源有限（主要是电池供电）且资源有限的设备，如手机、机顶盒、PDA等。CLDC1.0的规范可以在jcp的网站上下载。
CLDC 的目标
1) 为小型的、资源受限的连接设备定义一个Java 平台标准 2) 允许向上述设备动态的传递Java 应用和内容 3) 使Java 开发人员能够轻松的在这些设备上进行应用开发
CLDC 的整体需求
1) 能运行在绝大多数的小型的、资源受限的连接设备上 2) 用CLDC 为上述设备开发的应用尽可能的不使用设备的本地系统软件 （做到与平台、设 备无关） 3) 定义能应用在绝大多数上述设备上的最小子集的规范 4) 保证在不同类型 上述设备之间代码级的可移植性和互操作性 1. CLDC 的硬件需求 由于CLDC 要面向尽可能多的设备，而这些设备所使用的硬件又各不相同。因此CLDC 规范中并没有指明需要某种硬件支持，只是对设备的最小内存进行了限制。CLDC 规范中要求硬件必须达到以下要求： 1) 至少160KB 的固定内存以供虚拟机和CLDC 核心类库使用。 2) 至少32KB 的动态内存以供虚拟机运行时使用（堆栈等）。 这里所说的固定内存是指拥有写保护，不会因关机而抹去的ROM。对于具体的设备的具体实现，这 些需求也可能有变化。这里所规定的160KB 是CLDC 规范中的要求，实际也可以是128KB 左右。 2. CLDC 的软件需求 和硬件类似，CLDC 上运行的软件也是多种多样的。例如，有些设备支持多进程操作系统或者支持文件 系统；而有些功能极其有限的设备并不需要文 件系统。对于这些不确定性，CLDC只定义了软件所必须的最小集合。CLDC 规范中要求操作系统不需要支持多进程或是分址空间寻址，也不用考虑运行时的协调和延迟；但是必须提供至少一个可控制的实体来运行虚拟机。
CLDC的功能范围
4.1 CLDC包含的功能在CLDC1.0版本中定义了以下功能： 1）Java核心语言与Java虚拟机 的特性 2）核心Java类库 3）输入/输出 4）对网络的支持 5）对安全性的支持 6）对国际化的支持 4.2 CLDC不包含的功能1）对应用程序生命周期的管理 2）用户界面 3）事件处理 4）高级应用程序模式 （这里指用户与应用程序的交互） 4.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 ）来完 成的。 4.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对象的控制，如使用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的子类都未被支持，这包括异步异常。这是因为在嵌入式系统 中，应用程序并不期望获得设备的出错处理 机制；定义和运行出错处理需要较大的虚拟机的开销，而这些出错的代码信息对于连用户界面都没有的有限连接设备来说是没有用处的。
CLDC的安全机制
5.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规范中并没有详细的规定。 5.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把它交给了设备自己去实现。设备可以根据自身的需要在加载类或是安装应用程序的过程中执行。在运行时，虚拟机迅速地对字节码进行 线性扫描，将每个有效的指令与合适的堆栈映射项相匹配。运行时的审核过程是建立在预审核机制之上的，所以比预审核还要快，占用的动态内存更少。 5.3 CLDC中的类的文件格式 CLDC要求所有第三方开发的支持CLDC的Java应用程序在公开发布时都要使用JAR包的 格式，而且JAR包内的类必须是经过了预审核器审核之后的。同样的，CLDC要求所有实现CLDC的虚拟机也必须能够识别和调用JAR包中的文件。
MIDP（Mobile Information Device Profile，移动信息设备配置文件）建立在 CLDC 的基础之上，用来描述手机和寻呼机这样更加具体化的的无线移动设备。
对于 Java ME 平台，MIDP 定义了一个标准的 Java API 集合，此集合与联网的受限设备配置 CLDC 一起提供了一个面向移动信息设备（如移动电话、双向寻呼机和无线个人电脑 记事本 ）的完整 Java ME 应用程序 运行 环境。 功能