I did a little more research into J2ME. There are currently two levels of J2ME compliance. There is the very minimal CLDC platform which specifies a *very* constrained device. The device needs to place the VM, config libraries, profile libraries, and applications must all fit within a total memory budget of 160-512 KB. More specifically, 128KB of non-volatile memory exist for the VM and CLDC libraries and at least 32KB of volatile memory are available for the Java Runtime and object memory. That is very difficult to program for using something like Avalon.
CLDC has the Java language (minus floating point support!), core libraries (java.lang.*,java.util.*), IO, networking, security, and i18n. More specifically, it has a subset of java.lang.*, java.util.*, and java.io.*. The rest of the stuff is in javax.microedition.*. The i18n is also strictly limited to Readers and Writers (i.e. unicode support). What is not addressed is application life-cycle management (installation, launching, deletion), user interface functionality, and high level application models. They are addressed by "profiles" implemented on top of CLDC. The JVM is further crippled by lack of floating point support, the finalize() method, and reflection. While we can successfully work around the floating point and finalize() method, reflection poses a problem for the current way we do things. I will address this later below. Libraries that are eliminated include: JNI, user-defined classloaders, reflection, thread groups and daemon threads (although some devices do support Threads), finalization, and weak references. Also note that JARs *must* be compressed. The minimum collections that are supported are Vector, Stack, Hashtable, and Enumeration (going back to JDK 1.1 days). There are also no Properties supported--with the exception of 4 platform defined properties accessed *only* by System.getProperty(). A profile on top of CLDC that makes sense for us is MIDP. It adds a number of classes that will make life easier for us. Among the features are application lifecycle, application signing model and priviledged domains security, https, MIDlet push model, networking, persistent storage, sound, timers, and UI features. In MIDP profiles, we have access to Resources in the classloader. GENERATIVE PROGRAMMING ---------------------- Due to the constraints of J2ME environments, we need to seriously look at generative programming as a solution. We don't have any way of storing or reading information persistently until MIDP, so all our descriptors, configurations, etc. must be hardcoded. To make it easier on the developer of J2ME devices, we need to keep all the advantages of using XML descriptors for the container but use a compiler to convert those descriptors into code. Also due to the constraints of J2ME environments, we need to look at generating classes to handle the custom lifecycle of the components. We can't use reflection to create instances, or classloaders to protect our environment. The Configuration and Parameters APIs need to be altered due to the limitations of the J2ME VM (no floating point operations, no Java2 collections). When all is done, our J2ME container will be "generated" from the typical set of configuration files. The components need to be J2ME friendly, which might not allow for the configuration object and force us to only use Parameters for that need. It also forces us to keep our interfaces and implementations in separate JARs. The implementations will always be container specific, so it makes sense that they would be implemented by the container. The final application that is deployed on the J2ME device will be completely hard-wired and not dynamic--but it is "pregenerated" by our tools. Hopefully this will help us understand the bare minimum constraints that we need to operate within. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
