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 应用程序运行环境。　　功能

功能

·显示工具箱　　·用户输入方法　　·持久性数据存储（使用简单的面向记录的数据库模型）　　·基于 HTTP 1.1 的网络（使用 CLDC 通用连接框架）

MIDP 1.0

MIDP 1.0 提供了以下功能：　　·显示工具箱　　·用户输入方法　　·持久性数据存储（使用简单的面向记录的数据库模型）　　·基于 HTTP 1.1 的网络（使用 CLDC 通用连接框架）　　Java 规范请求 (Java Specification Request, JSR)-37 中定义了 MIDP 1.0 标准。

MIDP 2.0

JSR-118 中定义了 MIDP 2.0 标准。　　MIDP 2.0 于 2002 年 11 月正式发布，MIDP 2.0 的推出在一定意义上增强了 Java ME 的功能，主要体现在如下几个方面。　　（1）支持操作图像的像素，支持 Alpha 通道。　　（2）增强型的图形用户界面类 CustomItem，提高了高级界面类的表现力。　　（3）Media 音频子系统填补了 MIDP 1.0 不支持声音播放的空白。　　（4）Push 注册机制和安全模型增强了对 MIDlet 的控制。　　（5）游戏开发包提高了游戏开发的效率。　　（6）联网能力增强，可以支持 TCP/IP 甚至是 UDP 层的通信。

MIDP 2.1

1、 一个TextField或一个TextBox的最小尺寸（存储容量）不能少于1000个字符。 　　2、 LCDUI布局指令必须被遵循 。　　3、 LayoutManager.insert()方法的行为必须依照以下的描述：insert(Layer,int)　　描述　　Public void insert(javax.microedition.lcdui.game.Layer l,int index)　　插入一个新的Layer对象到LayoutManager在指定的索引值　　描述：　　插入一个已经被添加到这个LayoutManager的Layer对象等于先使用LayoutManager.remove()方法删除它，再用insert()方法添加到特定的索引。在LayoutManager.remove()方法被调用前，抛出IndexOutOfBoundsException的情况被检查　　参数：　　Layer l：被插入的Layer对象　　int Index：在被添加的新的Layer对象的索引值 。　　异常抛出：NullPointerException：如果Layer对象为null　　IndexOutOfBoundsException：如果索引值小于0。如果索引值大于已经被添加到LayoutManager中的Layer对象的数量且Layer对象不能被添加到这个LayoutManager中。如果索引值大于已经被添加到LayoutManager中的Layer对象的数量且Layer对象已经被添加到这个LayoutManager中 　　4、 一个带有item Command对象且表示模式是Item.PLAIN的StringTtem对象必须总是被作为添加了Command对象且表示模式是Item.HYPERLINK的StringTtem对象的方式显示。 　　5、 许多的MIDP LUDUI图像组件能包含文本（换句话说，一个字母数字字符），那被显示给用户。这些组件的例子是List, TextBox , Alert , StringItem ,Form和Item。一个实现常常需要截断这些可见的文本因为不能适合被给的UI组件的指定空间。在这种情况下，一个实现必须使用一个适当的可视化指示（例如一个省略符号）来指示用户，文本被截断。实际的符号或被用来显示截断的文本的符号以来于当前设备选择的区域设置。然而，可视化指示应该和用在设备本地的UI的指示一致。 　　6、 Canvas的触摸事件必须被支持，如果基础硬件支持这个特色。在这种情况下，Canvas.hasPointerEvents()方法应该总是返回true。 　　7、 Canvas的触摸拖曳事件必须被支持，如果基础硬件支持这个特色。在这种情况下，Canvas.hasPointerEvents()方法应该总是返回true。 　　8、 Canvas的重复事件必须被支持。在这种情况下，Canvas.hasRepeatEvents()方法应该总是返回true。 　　9、 双缓冲图像必须被支持。在这种情况下，Canvas.isDoubleBuffered()方法应该总是返回true。 　　10、 不同的文本输入模式的可用性（例如：预言输入和仅仅是数字的输入）应该和Java和本地的应用程序相一致。这意味着，例如，如果预言输入文本模式在本地应用程序中可用，那也应该在Java应用程序中可用。 　　11、 Image对象的创建（不管格式）必须至少支持：尺寸等于（屏幕宽度）乘以（屏幕高度）乘以（以字节为单位的颜色深度）或262144比特（128×128×16比特＝32KB），无论哪一个更大。注意，一个Image对象的内在表现应该保持至少每个象素16字节的颜色/透明度数据 　　12、 每一个包括在字符串值的通过System.getProperty(“microedition.commports”)方法返回的串行端口名字必须可获取通过javax.microedition.io.CommConnection接口 　　12、 在每个协议，AllowedSender域必须匹配适当的输入事件的地址域。地址域的使用和语法和语意以来于协议。然而，地址和过滤器必须被比较通过精确的字符串匹配，在那里，字符串被一个接着一个字符的比较，字符需要正确地匹配通过两个通配符 　　13、 以下地网络通信协议必须被支持，提供了以下Java ME接口的实现：javax.microedition.io.SockerConnection , javax.microedition.io.SecureConnection, javax.microedition.io.HttpsConnection 　　14、 javax.microedition.io.HttpsConnection和javax.microedition.io.SecureConnection必须支持SSLv3协议，其它的，例如TLS,WTLS也许被支持。 　　15、 应用程序描述符应该包含MIDlet-Permissions 　　16、 以下的JAD/manifest文件属性被定义来支持指定预期的运行时执行环境：Runtime-Execution-Environment：这是一个可选的属性，指出了应用程序必须的运行时执行环境。这个属性也许有值MIDP.CLDC.如果MIDlet suite不指定属性，隐含的默认值是MIDP.CLDC。当值是MIDP.CLDC，实现的行为必须坚持在以下显示的更多的细节描述。这个属性值的附加值被在将来定义。手机实现必须支持这个属性。当值是MIDP.CLDC，实现的行为必须坚持以下要求：1、支持API和API行为，以及基础虚拟机，必须顺从CLDC1.1规范。2、手机实现也许二选一地使用Java ME的CDC规范。然而，如果CDC被用作基础配置，运行在这个平台顶端的应用程序必须看见一个语义学和功能上等于CLDC1.1平台的环境。CDC特定的API或者CDC特定行为必须不能被暴露给应用程序或应用程序开发者。3、当一个应用程序定义了Runtime-Execution-Environment属性值，应用程序必须也定义一个CLDC平台在MicroEdition-Configuration属性值中。4、如果一个应用程序定义了不被实现支持的Runtime-Execution-Environment属性值或MicroEdition-Configuration属性值，应用程序不能被安装。所有的手机实现必须支持MIDP.CLDC值对于Runtime-Execution-Environment属性。 　　17、 用户使用OTA下载安装之后，实现必须提示用户是否启动MIDlet 　　18、 实现必须允许MIDlet创建最小为10个的线程 　　19、 支持至少512个属性 　　20、 支持MIDlet suite包含1到5个MIDlet 　　21、 每个MIDlet suite的RMS至少保证64K的空间，在内存足够的情况下 　　22、 每个MIDlet suite至少可以创建10个独立记录存储 　　23、 MIDP的MMAPI的子集必须遵守MMAPI1.1或以后版本 　　24、 MicroEdition.profiles系统属性不能包含相同profile的不同的版本 　　25、 Image对象中ISO/IEC JPEG和JFIF被支持 　　26、 支持载入深度为1、2、4、8、16和32位的PNG格式 　　27、 TextBox和TextField的约束TextField.EMAILDDR和TextField.URL必须允许相同的字符被输入如同被允许输入在TextField.ANY约束下 　　28、 适合的设备必须实现基于时间的推注册，如果没有其它的安全机制基于时间的推注册不需要被显式的用户的许可