J2ME in a Nutshell（翻译版） :第二章 连接有限设备配置CLDC,2.1.2安全特性

2.1.2安全特性

在J2SE平台上，安全模型是足够的强大以允许不同来源的代码具有不同的权限，这样就创建了系统的不同访问级别。在终端，安装在用户系统上的应用，确省的，拥有不受限的访问权限。然而，一个来之不受信任网站的applet程序是在受限的环境中运行 的，并且不允许访问本地的文件资源，如用户的文件系统和有限的网络访问。在这两种极限情况下，安全模型允许权限被授予给或者拒绝一个应用和基于来源的信任等级的applet。信任的代码可以使用能够提供代码来源保证的证书来发送，也可以使用数字签名来防止代码在传输过程中被修改。

CLDC虚拟机可以在不允许用户安装代码的设备中，那样也就没有安全特性的需要了。它也可以使用在蜂窝电话的网络连接中心来允许用户下载应用，可能来之不信任的地方。网络必须是受到与J2SE applet相同的安全限制的约束。对于受信任的代码使用中等的安全等级将是有用的。不幸的是，通常这样并不实用，精细的J2SE安全模型、验证数字签名和证书需要太多的存储和处理能力，这些能力对于CLDC规范的设备来说太大了。所以，CLDC虚拟机在沙箱（sandbox）中运行应用以使得它不能恶意的损坏设备。下面简要总结了虚拟机创建沙箱所作的限制。

2.1.2.1类装载控制

每一个CLDC实现必须有自己的类装载器，这样可以装载主设备支持的位置的类，特别是在网络上或者设备本身的存储。不像J2SE，应用程序不允许创建自己的装载器并且不能影响系统的装载器用于搜索和定位类的进程。（换句话说，不能改变系统的CLASSPATH和等价的变量）

这种限制的直接结果就是应用代码不能在java和javax.microedtion包中放置核心类的自己版本。如果这个被允许的话，可能造成java运行环境的安全问题。系统类装载器通常忽略应用程序中声明在这些包中的类。

2.1.2.2访问本地代码

CLDC没有包含JNI的实现，所以也就不可能动态的连接本地代码，即使可以这些可以安装作为应用程序的一部分。这样做的一个副作用，就是也阻碍了直接访问设备操作系统提供的功能，除非CLDC或者它的一个概要能够提供这种java接口。这个限制阻碍了应用程序读取或者修改用户希望的信息。

然而，通过预先连接额外的本地代码给虚拟机，这样就可能扩展API给java应用，但是这种应用程序只能安装在用户自定义的虚拟机上，所以也就不存在一般意义上的安全问题，详细请参照2.4.2节。

2.1.2.3类验证

J2SE通常提供一个字节代码的验证器来检查java来的完整性。这样就保证了类文件不会因没有支持java语言规则（通常由java编译器来检查和保证）而造成系统安全隐患：

ü 所有的局部变量在使用前必须被初始化

ü 创建一个对象，它的构造器必须在使用前被调用

ü 每一个构造器必须以调用父类的构造器为开始（异常就使用java.lang.Object的构造器）

ü 用于包含对象引用的局部变量和事例和静态成员必须包含该对象的引用或者分配给它的引用。例如，把一个指向TimerTask的变量指定为一个Timer的引用是不合法的。

确省的情况下，J2SE虚拟机运行字节代码验证器来验证从外部装载的类，而不是从本地文件系统。在移动的环境中，通常建议对所有的应用都进行验证。然而，进行检查的算法是非常消耗处理能力并且需要大量的内存，所以它们不能在CLDC面向的设备上。正是这个原因，类文件分成两个阶段来进行：

1. 预验证是在类文件被安装到设备上之前进行的。这个处理包含了大多数复杂和耗时的字节代码验证算法，并且作为编译的部分或者编译完立即进行。预验证的结果放在类文件中，可以在运行的时候访问它们。

2. 运行试验正在设备上进行。依据设备的特性，这个操作在类装载或者作为安装进程的部分进行，前提就是安装的代码安装的代码不能被更改。这个过程使用预验证提供的信息，结合线性地扫描字节代码来保证所有的语言规则都被遵守了。这个过程是非常快的并且需要少得多的内存。

为了编译和运行CLDC应用，你不必要了解预验证和运行验证的很多内容。但是你可以在CLDC规范中得到详细内容。