Hi, CLDC supports 2 types of security mechanisms, Low level security and application level security. The application security makes the Midlet suite to run inside a Sandbox model. Hence a midlet suite can't access any other midlet suite. So your requirement can't be facilitated.
SCJP 1.4, SCMAD 1.0<br />SCWCD, SCBCD (in progress)
You can try using Push Registry alarms, if the device supports it. This basically allows scheduling in time the execution of another MIDlet in the *same* MIDlet suite ie implying they are part of the same jar. [ October 12, 2007: Message edited by: Eduardo Marques ]
If a Midlet from one .jar cannot instantiate for execution a Midlet in another .jar on the same device, how does a new Midlet application get installed on a device by download, etc. when it didn't come in the initial .jar on the device? It would seem to maintain the single .jar restriction that a device must be able to add a Midlet (and all its supporting classes and resources) to the single .jar, or delete them, and update the .jar manifest accordingly. That sounds like a lot of overhead for what appears to be a common device behavior. What classes and methods in the CLDC MIDP support this manipulation?
I would appreciate an explanation of a good approach to management of dynamic content under these conditions. What specific capabilities, features, classes, and/or methods must be implemented in the device profile to accommodate dynamic applications and content?