|
|
Classification: |
Java |
Category: |
J2ME MIDP |
Created: |
09/08/2004 |
Modified: |
09/10/2004 |
Number: |
FAQ-1130 |
Platform: |
Symbian OS v7.0, Symbian OS v7.0s, Symbian OS v8.0 |
|
Question: "MIDlets run in a sandbox". What does this mean in practice?
Answer: The memory requirements of the J2SE security classes alone exceed the total memory budget available to J2ME CLDC/MIDP. Hence
the J2ME CLDC specification dictates a much simpler "sandbox" security model.
A MIDP application (MIDlet) therefore runs in a closed environment and is only able to a access a predefined set of classes
and libraries supported by the device.
A CLDC VM has a built in class loader. This class loader can however only load classes from the predefined set of system
classes or the application (MIDlet) JAR file. To avoid this restriction being bypassed, unlike a J2SE VM, the class loader can not be replaced, overriden
or reconfigured by the user.
Similarly there is no support for loading native libraries via System.loadLibrary and no support for JNI.
In short it is not possible for the user/developer to extend the range of libraries (APIs) supported by a CLDC/MIDP phone
beyond the pre-defined set that was built in to the device.
Your application (MIDlet) may make use of third-party pure Java CLDC/MIDP libraries such as kSOAP or kXML by incorporating
them into the application JAR file. Obviously such third-party libraries must be written entirely in Java (no native code) using the CLDC/MIDP API.
|
|
|