对程序开发人员来说，碎片真是个恶梦，因为碎片平白无故的增添了代码量和测试工作量。当然，对移动电话持有者来说也不是什么好事，因为碎片消耗了设备的空间。不管怎么说，碎片对每个人来说都是件很讨厌的事情。

　　但对于嵌入开发者而，碎片又意味着什么呢？

　　首先来看看碎片产生的根源。移动电话行业标准本来给不同的产品预留了一定的自由空间，这初衷是好的。但事实上，这种预留的空间，却导致了不同产品之间的冲突，不能进行很好的兼容。这就是碎片产生的最根本原因。于是这种不兼容性进而升级到了Java实现的程序里。这正是Java想花大力气创建一个统一Java实现的原因所在，如JSR248,MSA（Mobile Service Architecture）的建立。

　　从嵌入式开发人员的角度来看，也许并没有这么糟糕。其实碎片并不会影响到嵌入式开发人员，因为已经可以确定设备之间的硬件是完全兼容的。如果使用的是原始语言像C/C++的话，嵌入式开发人员可以在任何地方来编写代码，并在不同的设备上进行代码的重用。

　　三、 Java平台的测试

　　如果采用Java来实现嵌入式设备开发，会不会碰到C/C++经常碰到的测试成本太高的难题呢？

　　当然，采用Java来开发的话，可以对软件进行多次的重复测试，尽管这不一定是必需的。而完全需要进行重复测试的只是那些新加的Java实现。如果是Java平台的合法用户的话，还可以使用Sun提供的TCK来进行程序兼容性的检测。如果付费的话，还有很多压力测试可供选择。只要能保证Java平台的正常运行并按Java的测试通过了的话，那么所开发的程序其可移植性是完全可以保证的。

　　当然，在此有必须有提醒一下只测试Java实现端口的开发人员。因为有一些端口的实现有可能是采用C/C++来编写的，这些必须测试。可以使用全新设备来对整个程序进行测试以达到这一目的。

　　1. 测试工具包

　　通过采用来进行编程，可以确保平台的APIs是否正确的工作。如果采用C/C++或直接对操作系统编程，则使用全新的设备时，无法保证APIs的正常性。由于这些问题取决于所采用的测试包的全面性和可靠性，因此，在开发阶段有可能发现不了它们，而在部署的阶段发现了它们时，问题已经扩散得超出控制范围了。而对于Java平台的测试，一般比较全面。所以，C/C++或直接对操作系统编程的问题能比较早的被发现并解决。

　　因此，采用Java平台时，其测试时间有可能跟使用C/C++来开发整个程序的时间差不多。但结果大大不同，使用Java平台时，其最差的测试效果往往可以与C/C++环境下最好的测试效果媲美。就测试的选择而言，采用Java平台时，可以使用Sun的TCK来确保程序对新设备的适用性，同时，还可以得到Java的其它测试包，不过是收费的。然而使用C/C++时，则只能依靠开发人员自己来保证程序对新设备的适应性了。

　　2. 端口兼容性