The goal of the CLDC Specification is to standardize a highly portable, minimum-footprint Java™ application development platform for resource-constrained, connected devices.
The devices targeted by the CLDC Specification have the following general characteristics:
Cell phones, two-way pagers, sensors, wireless modules, IoT and M2M platforms, home appliances, low-end TV set-top boxes, and point of sale terminals are some, but not all, of the devices that might be supported by this specification.
More specifically, the CLDC Specification defines a Java application development platform with the following characteristics and goals:
Keep footprint small. Consumer devices such as cellular phones are manufactured in very large quantities (hundreds of thousands, millions, or even tens of millions of units per year). They are sold to price-conscious consumers at very low, often subsidized prices. To maintain profit margins, device manufacturers want to keep the per-unit costs of the devices as low as possible. Additional processing power or precious dynamic memory will not be added unless the consumers are willing to pay for the added capabilities. To meet the needs of the device manufacturers, the CLDC Specification defines a "lowest common denominator" standard that includes only the minimal Java platform features and APIs for a wide range of consumer devices.
Focus on application programming rather than systems programming. CLDC is intended to be primarily an application development platform, rather than a systems programming environment. This has certain implications for the Java platform features and APIs to be included in this specification. First, the CLDC Specification shall include only high-level libraries that provide sufficient programming power for the application developer. Second, we emphasize the importance of generality and portability. The CLDC Specification shall not provide any APIs that are specific to a certain device category, vertical market or system functionality.
Enable dynamic downloading of applications and encourage third-party application development. One of the key goals of the CLDC Specification is to define an environment that is well-suited for the dynamic, secure downloading of Java applications over different kinds of networks to small client devices.
CLDC is intended to run on a wide variety of small devices. The underlying hardware capabilities of these devices vary considerably, and therefore the CLDC Specification does not impose any specific hardware requirements other than memory requirements. Even for memory limits, the CLDC Specification defines only minimum limits. The actual CLDC target devices may have significantly more memory than the minimum.
The Specification recommends that:
512Kb of non-volatile1 memory is available for the virtual machine and CLDC libraries.
128Kb of volatile memory2 is available as a minimum, 256Kb is recommended for the virtual machine runtime (for example, the object heap.)
The ratio of volatile to non-volatile memory in the total memory budget can vary considerably depending on the target device and the role of the Java platform in the device. If the Java platform is used strictly for running system applications that are built in a device, then applications can be pre-linked and preloaded, and a very limited amount of volatile memory is needed. If the Java platform is used for running dynamically downloaded content, then devices will need a higher ratio of volatile memory.
Like the hardware capabilities, the system software in CLDC target devices varies considerably. For instance, some of the devices may have a full-featured operating system that supports multiple, concurrent operating system processes and a hierarchical file system. Many other devices may have extremely limited system software with a minimal file system. Faced with such variety, CLDC makes minimal assumptions about the underlying system software.
Generally, the CLDC Specification assumes that a minimal host operating system or kernel is available to manage the underlying hardware. This host operating system must provide at least one schedulable entity to run the Java Virtual Machine. The host operating system does not need to support separate address spaces or processes, nor does it have to make any guarantees about the real-time scheduling or latency behavior.
1. The term non-volatile is used to indicate that the memory is expected to retain its contents between the user turning the device "on" or "off". For the purposes of the CLDC Specification, it is assumed that non-volatile memory is usually accessed in read mode, and that special setup may be required to write to it. Examples of non-volatile memory include ROM, Flash and battery-packed SDRAM. The CLDC Specification does not define which memory technology a device must have, nor does it define the behavior of such memory in a power-loss scenario.
2. The term volatile is used to indicate that the memory is not expected to retain its contents between the user turning the device "on" or "off". For the purposes of the CLDC Specification, it is assumed that volatile memory can be read and written to directly without any special setup. The most common type of volatile memory is DRAM.
Copyright (c) 2014, Oracle and/or its affiliates. All Rights Reserved. Use of this specification is subject to license terms.