基于cldc+midp的无线应用程序具有与生俱来的安全特性，这得益于java语言和java平台的安全机制。即使是有破坏性的程序也只能伤害到虚拟机层，不会伤害到手机操作系统。本文并不是要专门针对midp2.0的安全体系结构进行介绍，而是力图结合java语言、虚拟机等方面的安全设计谈谈无线应用的安全结构。
　　
　　java语言具有安全的特性，这得益于下面三个方面的支持。
　　
　　java语言是健壮的、安全的
　　在java中规定了所有原始数据类型的精确尺寸，并且这不依赖于底层的操作系统。java具有非常出色的异常处理机制，对数组越界操作和公指针操作提供检查，一经发现会抛出异常。要知道如果在c语言中由于程序的不健全导致数组越界操作是非常危险的事情。java中采用的是引用机制，没有提供指针运算的操作。以上几点确保了java语言本身的安全性。
　　
　　java编译器和运行环境
　　java的编译器和运行环境通过提供的一些特性来确保安全的实现，这些特性包括：类装载、class文件验证。总之，这将确保java程序必须要在一个jvm规范允许的范围内运行。如果读者有兴趣可以参考一下《深入java虚拟机2》
　　
　　securitymananger
　　以上两个方面可以确保怀有恶意的代码不被执行，这样虚拟机就不会被破坏。但是针对applet或者非信任的网络程序则无能为力，java中定义了securitymanager类允许用户订制安全政策，什么代码可以被执行，什么不可以被执行。
　　用过applet的程序员都知道沙箱这个词，它同样是为了确保安全。applet的运行需要从网络上下载到本地上来，在你确认它是否安全之前让它访问你的本地资源的话那将是非常危险的事情。因此java采用了沙箱的机制，让applet运行在一个受限的环境内。
　　　
　　由于j2se中的安全机制需要很大内存的支持，因此在j2me（cldc+midp)中并没有采取。在j2me中采用的是两层安全结构，包括底层的kvm安全机制和上层的应用程序安全机制。
　　
　　在kvm的安全机制中，主要是通过class文件验证来确保安全的，一旦这个class文件是非安全的，比如它含有对危险内存空间的引用，那么kvm将不会运行它的。但是由于class文件在验证上比较消耗时间，因此kvm的设计人员把这部分工作移植到开发阶段了，我们看到源文件在编译后会被验证，你可以仔细看看ktoolbar的控制台输出。而在kvm里面做的验证都是简单的。
　　
　　在应用程序层进行的限制主要是为了防止应用程序恶意破坏文件系统等设备。由于考虑到性能的问题，他没有采取securitymanager类的策略。因此与传统的沙箱不同的是，基于cldc/midp的沙箱模型作了如下的限制。
　　
　　class文件必须是经过验证并有效的
　　系统只提供了一部分预定义的api给开发人员，为了安全的因素jni、用户定义的类装载器都不被支持
　　下载和管理应用程序由kvm完成，用户不能自己实现
　　开发者不能下载并使用任何包含访问本机方法的类库，只限于cldc/midp和可选包。