A configuration specifies a JVM and some set of core APIs for a specific family of devices. Currently there are two.
A connected device has, at a minimum, 512KB of read-only memory (ROM), 256KB of random access memory (RAM), and some kind of network connection. The CDC is designed for devices like television set-top boxes, car navigation systems, and high end PDAs. The CDC specifies that a full Java Virtual Machine (as defined in the Java Virtual Machine Specification, 2nd edition) must be supported.
The configurations and profiles of J2ME are generally described in terms of their memory capacity. Usually a minimum amount of ROM and RAM is specified. For small devices, it makes sense to think in terms of volatile and non-volatile memory. The non-volatile memory is capable of keeping its contents intact as the device is turned on and off. ROM is one type of non-volatile memory, but this could also be flash memory or memory-backed RAM. Volatile memory is essentially workspace and does not maintain its contents when the device is turned off.
The CDC is being developed under the Java Community ProcessSM. For more information on the CDC, see http://java.sun.com/products/cdc/. A Linux reference implementation is available.
J2ME configurations and profiles are created under the aegis of the Java Community Process (JCP). The JCP is designed to insure that Java technology is developed according to community consensus. The process is described here: http://java.sun.com/aboutJava/communityprocess/.
Configurations and profiles first appear in the world as Java Specification Requests (JSRs). You can see a list of current JSRs here: http://java.sun.com/aboutJava/communityprocess/search.html.
CLDC is the configuration that interests us, because it encompasses mobile phones, pagers, PDAs, and other devices of similar size. CLDC is aimed at smaller devices than the CDC. The name is a little misleading; really, the CLDC is designed for a small device with a limited network connection-"Limited Connection Device Configuration" might have been more accurate.
The CLDC is designed for devices with 160KB to 512KB of memory available for the Java platform. If you've ever watched J2SE gobble up tens of megabytes of memory on your desktop computer, you'll appreciate the challenge of J2ME. The "limited connection" simply refers to a network connection that is intermittent and probably not very fast. (Most mobile telephones, for example, typically achieve data rates of 9.6Kbps.) Between the small screen size, limited memory, and slow network connection, applications designed in the CLDC space should be very sparing with the use of the network connection.
The CLDC is based around a small JVM called the KVM. Its name comes from the fact that it is a JVM whose size is measured in kilobytes rather than megabytes. While the CLDC is a specifications document, the KVM refers to a specific piece of software.[1] Because of its small size, the KVM can't do everything a JVM does in the J2SE world.
Native methods cannot be added at runtime. All native functionality is built into the KVM.
The KVM only includes a subset of the standard bytecode verifier. This means that the task of verifying classes is split between the CLDC device and some external mechanism. This has serious security implications, as we'll discuss later.
You can find more information at the CLDC home page, http://java.sun.com/products/cldc/. For a full list of differences between KVM and JVM, see the technical article on http://developer.java.sun.com/developer/technicalArticles/wireless/midpapi/.
In the next generation of J2ME, a concept called Building Blocks will replace configurations. A Building Block is just some subset of a J2SE API. For example, one Building Block might be created from a subset of the J2SE java.io package. Conceptually, it represents a smaller chunk of information than a configuration. Profiles, then, will be built on top of a set of Building Blocks rather than a configuration.
The definition of Building Blocks is itself a JSR, which is briefly described here: http://java.sun.com/aboutJava/communityprocess/jsr/jsr_068_j2me.html.
[1]The KVM was originally part of spotless, a Sun research project. See http://www.sun.com/research/spotless/.
Team-Fly |