J2SE existing security stem was too large to fit the constraints of the CLDC target platform; it alone would likely have exceeded all available memory. A resived model cuts down many of the features, but requires far than resources. The good news is that this simplification makes it much easier to cover all the details.
There are two main sections to the CLDC security model:
- Virtual Machine security
- Application security
The goal of the virtual machine security layer is to protect the underlying device from any damage executable code might cause. Under normal circumstances, a bytecode verification process carried out prior to any code execution takes care of this. This verification process essentially validates class file bytecode, thus ensuring it is correct for execution. The most important result of this process is the protection it offers againts the execution of invalid instructions -or worse, the creation of scenarios in which memory outside the Java environment is corrupted. Not pretty.
The standart bytecode verification prcess used with J2SE requires about 50 Kb of code space, along with up to 100 Kb of heap. While this is negligible on larger systems, it constitutes pretty much all the memory available to Java on many micro devices. Althought I have a great desire to spend all my resources doing program verification, smoe rude people insist on something more, like any form of application. So in an effort to appease this demanding bunch, the CLDC specifications provide an alternative.
The resulting verification implementation within the CLDC's virtual machine requires around 10 Kb of binary code space and as little as 100 bytes of run-time memory. From a dynamic memory standpoint, this is a reduction of about 1,000 times. Someone needs to get a little star stamp on the forehead for that one!
The reduction in resources essentially -comes from the removal of the iterative dataflow algorithm from the in memory verification process. The price is that you now have to undertake an additional step known as pre-verification to prepare code for execution on the KVM. The result of this process is the insertion of additional attributes into the class file.
A tool supplied with the J2ME development environment carries out the process of pre-verifying. It 's all rather painless. The important point is that the resource-intensive part of the verification process is carried out on your (overpowered) development PC (the build server).
Application Security
The class loader verification process discussed prviously is pretty limited. Basically, it just validates that bytecode is the legitimate result of the Java compilation process. Althought this is helpful, a further level of security is required to protect a device's resource.
As you might have guessed, the powerful (but rather large) J2SE security model is out that window. The CLDC incorporates a simplified security model based on the concept to protect a sandbox.
The term sandbox really just means that your Java code can play only within the confines of a small, controlled environment. Even if that big blue truck you love is outside and you really wanna play with it, you can't. Anything outside is completely out of bounds. So stop trying, or you 're going to your room!
Your code has restricted what's available in the sandbox environment. The CLDC defines a list of exactly what you can execute, and that's all you get. Protection is also in place so you can't change the base classes that make up the istalled API on the device-the so called core classes.
The CLDC specifcation mandates protection for these classes.
Application Management
Managing applications on micro devices is quite a different experience than doing so on typical PCs. Quite often there is no consept of a file system, let alone a file browser. In some extreme cases, micro devices won't even store class file permanently, the delete them after you finish playing.
Most of the time, especially on typical mobile devices, users have a limited amount of application space in which to store their favorite programs. (This space will be filled with your games, of course.)
To manage these applications, the device should provide a basic ability to review the installed applications, launch an application, and then subsequently delete it if the user so desires.
The CLDC doesn't mandate the form the application manager should take, however, typical implementations are simple menu based tools to browse and launch programs. Nothing fancy, but they certainly do the job.