By: Ivan Lim Emailed: 1728 times Printed: 2331 times
• The types and amount of memory available
• The processor type and speed
• The type of network connection available to the device
A configuration is supposed to represent the minimum platform for its target device and is not permitted to define optional features. Vendors are required to implement the specification fully so that developers can rely on a consistent programming environment and, therefore, create applications that are as device-independent as possible.
J2ME currently defines two configurations:
Connected Limited Device Configuration (CLDC)
CLDC is aimed at the low end of the consumer electronics range.
A typical CLDC platform is a cell phone or PDA with around 512 KB of available
memory. For this reason, CLDC is closely associated with wireless Java, which is
concerned with allowing cell phone users to purchase and download small Java
applications known as
MIDlets to their handsets. A large and growing number of
cell phone vendors have signed agreements with Sun Microsystems that will allow them to
begin using this technology, so the number of handsets with the capability to be
programmed in Java
will probably grow rapidly in the next few years.
Connected Device Configuration (CDC)
CDC addresses the needs of devices that lie between those addressed by CLDC and the full desktop systems running J2SE. These devices have more memory (typically 2 MB or more) and more capable processors, and they can, therefore, support a much more complete Java software environment. CDC might be found on high-end PDAs and in smart phones, web telephones, residential gateways, and set-top boxes. Each configuration consists of a Java virtual machine and a core collection of Java classes that provide the programming environment for application software. Processor and memory limitations, particularly in low-end devices, can make it impossible for a J2ME virtual machine to support all of the Java language features or instruction byte codes and software optimizations provided by a J2SE VM. Therefore, J2ME VMs are usually defined in terms of those parts of the Java Virtual Machine Specification and the Java Language Specification that they are not obliged to implement. As an example of this, devices targeted by CLDC often do not have floating point hardware, and a CLDC VM is therefore not required to support the Java language types float and double or any of the classes and methods that require these types or involve floating-point operations.
It is important to note that configuration specifications do not require implementations to use any specific virtual machine. Vendors are free to create their own VM or license a third-party VM, provided that it meets the minimum requirements of the specification. Sun provides reference implementations of both configurations, each of which includes a conforming virtual machine:
- The CLDC reference implementation is a source code and binary product for the Windows, Solaris and Linux platforms. It includes the Kilobyte Virtual Machine (KVM), a reduced-functionality VM that has a very small memory footprint and incorporates a garbage collector that is optimized for a memory-constrained environment. KVM, which is discussed in Chapter 2, is likely to be used as the basis for most CLDC implementations in the near future, but there are other VMs that could be used instead, such as the J9 VM from IBM.
- The CDC reference implementation is a source code-only product for Linux and the Wind River VxWorks real-time operating system. The VM included with this product, called CVM (see Chapter 7), implements the full range of J2SE VM features as required by the CDC specification. However, it does not include the HotSpot technology found in the J2SE Version 1.3 VM or even a just-in-time compiler (JIT) as found in earlier J2SE releases. Several third-party vendors, including Insignia Solutions and IBM, have plans to release their own CDC implementations that include different virtual machines.
A configuration also includes a core set of Java language classes. The core class libraries defined for a configuration (and for profiles) are required to be based on those of the Java 2 platform. This promotes as much compatability as possible between applications written for different J2ME platforms and those written with J2SE, and it also reduces the learning curve for J2ME developers. Broadly speaking, this means that developers can rely on the following:
- Where possible, J2ME must reuse J2SE classes and packages. This means that, for example, it would not be acceptable for a J2ME configuration or profile to eschew the java.util.Date class and introduce one of its own.1 As a result, everything that you know about J2SE can be carried forward to J2ME, provided you know the exceptions that apply to the configuration and profiles you are working with. That information is available in the reference section of this book.
- When a J2SE class is incorporated into J2ME, new methods and fields may not be added to it. Similarly, new classes cannot be added to a coopted J2SE package. These rules ensure that code written for J2ME that uses only those classes it shares with J2SE will compile and work on J2SE, thus making it possible to share code between these platforms.
View Tutorial By: Vandana B.Dass at 2010-02-01 00:54:54
View Tutorial By: vishal at 2013-02-11 03:50:04
View Tutorial By: Narayana at 2013-02-21 10:08:27
Most Viewed Articles (in J2ME )
Most Emailed Articles (in J2ME)