The Java Platform, Standard Edition 8 [Java SE8] provides a very rich set of libraries for the development of applications for desktop computers and server machines. Unfortunately, these libraries require multiple megabytes of memory to run, and are therefore unsuitable for small devices with limited resources.

A general goal for designing the libraries for the Connected Limited Device Configuration is to provide a minimum useful set of libraries for practical application development and profile definition for a variety of small devices. As explained in Goals CLDC is a lowest common denominator standard that includes the minimal Java platform features and APIs for a wide range of consumer devices. Given the strict memory constraints and differing features of today's small devices, it is virtually impossible to come up with a set of libraries that would be ideal for everyone. No matter where the bar for feature inclusion is set, the bar is inevitably going to be too low for some devices and users, and possibly too high for some others.

To ensure upward compatibility with larger editions of the Java Platform, the libraries included in CLDC are a strict subset of Java SE. While upward compatibility is a very desirable goal, Java SE libraries have strong internal dependencies that make subsetting them difficult in important areas such as security, input/output, user interface definition, networking and storage. These dependencies are a natural consequence of design evolution and reuse that has taken place during the development of Java libraries over time. These dependencies make it difficult to take just one part of the libraries without including several others.

CLDC API Alternatives

The libraries defined by the CLDC Specification are the Full and Compact APIs. The Compact CLDC API may be implemented as an alternative to the Full CLDC API. The microedition.configuration property indicates which APIs are implemented.

• CLDC Full APIs: Java runtime classes (java.lang), annotations (java.lang.annotation), weak references (java.lang.ref), collections, service loader, and utility classes (java.util), Security (java.security), I/O Streams and Readers (java.io), Network exceptions (java.net), NIO Buffers (java.nio), NIO Channels (java.nio.channels), NIO Files (java.nio.file and java.nio.file.attribute), and Logging (java.util.logging)
• CLDC Compact APIs: Java runtime classes (java.lang), annotations (java.lang.annotation), weak references (java.lang.ref), collections, service loader, and utility classes (java.util), Security (java.security), I/O Streams and Readers (java.io), and Network exceptions (java.net)

Classes derived from Java standard edition

CLDC supports a number of classes that have been derived from Java Standard Edition, Version 8 [Java SE8 API]. The rules for subsets require that each class that has the same name and package name as a Java SE class must be identical to or a subset of the corresponding Java SE class. The semantics of the classes and their methods included in the subset shall not be changed. The classes shall not add any public or protected methods or fields that are not available in the corresponding Java SE classes.

Internationalization

Character sets and character case conversion support

CLDC supports Unicode characters. Character information is based on the Unicode Standard, version 3.0. However, since the full character tables required for Unicode support can be excessively large for devices with tight memory budgets, by default the character property and case conversion facilities in CLDC assume the presence of ISO Latin-1 range of characters only. More specifically, implementations must provide support for character properties and case conversions for characters in the “Basic Latin” and “Latin-1 Supplement” blocks of Unicode 3.0. Other Unicode character blocks may be supported as necessary.

Standard charsets

Every CLDC implementation is required to support the following standard charsets. Consult the release documentation for your implementation to see if any other charsets are supported. The behavior of such optional charsets may differ between implementations.

Charset	Description
ISO-8859-1	ISO Latin Alphabet No. 1, a.k.a. ISO-LATIN-1
UTF-8	Eight-bit UCS Transformation Format

Character encodings

CLDC includes limited support for the translation of Unicode characters to and from a sequence of bytes. In Java SE this is done using Readers and Writers, and the same mechanism is utilized in CLDC for the InputStreamReader, OutputStreamWriter, PrintStream and String constructors with an additional parameter for the encoding.

• new InputStreamReader(InputStream is);
• new InputStreamReader(InputStream is, String charsetName);
• new OutputStreamWriter(OutputStream os);
• new OutputStreamWriter(OutputStream os, String charsetName);
• new PrintStream(OutputStream out, boolean autoFlush);
• new PrintStream(OutputStream out, boolean autoFlush, String encoding);
• new String(byte[] bytes);
• new String(byte[] bytes, String charsetName);
• new String(byte[] bytes, int offset, int length);
• new String(byte[] bytes, int offset, int length, String charsetName);

If the charsetName parameter is present, it is the name of the encoding to be used. Where it is not, a default encoding (defined by the system property microedition.encoding ) is used.

Implementations MUST support at least the preferred MIME name as defined by IANA ( http://www.iana.org/assignments/character-sets) for the supported character encodings. For example, for ISO-LATIN-1, the name ISO-8859-1 MUST be supported. If no preferred name has been defined, then the registered name MUST be used, for example, UTF-16.

Implementations MUST define a system property microedition.encoding which contains a valid string value for the default character encoding.

Implementations are strongly recommended to use UTF-8 for the default encoding (see [RFC2279]), since UTF-8 was determined to be the most feasible character encoding that covers all the required characters for international applications.

Support for the change in platform default character encoding affects the following API methods and classes :

• java.lang.String(byte[] bytes) - constructor that takes an array of bytes and interprets it in the platform default encoding
• java.io.InputStreamReader(InputStream is) - constructor that uses the platform default encoding to interpret the data that is read
• java.io.OutputStreamWriter(OutputStream os) - constructor that uses the platform default encoding to interpret the data that is written
• java.io.PrintStream - to print representations of data values
• java.io.ByteArrayOutputStream - using the toString method to translate bytes into characters

Method variants that take an explicit character encoding are not affected, so that a particular character encoding can still be requested by the application, provided that it is supported by the implementation.
Additional converters may be provided by particular implementations. If a converter for a certain encoding is not available, an UnsupportedEncodingException will be thrown. For official information on character encodings in Java SE, refer to Charset Encoding.

No localization support. Note that CLDC does not provide any localization features. This means that all the solutions related to the formatting of dates, times, currencies, and so on are outside the scope of CLDC Specification.

Timezone support

To conserve space, the CLDC Specification requires only one time zone to be supported. By default, this time zone is GMT. Additional time zones may be provided by manufacturer-specific implementations of CLDC, as long as the time zones are compatible with those provided by Java Standard Edition.

Property support

In CLDC, a limited set of system properties is available, which are listed below. These properties can be accessed by calling the method System.getProperty(String key).

Key	Explanation	Value
microedition.platform	Name of the host platform or device	(implementation-dependent)
microedition.encoding	Default platform character encoding	A valid name of a character encoding supported by the platform. Recommended value: "UTF-8"
microedition.configuration	Name and version of the supported configuration	"CLDC-1.8" for Full APIs "CLDC-1.8-Compact" for the Compact APIs
microedition.profiles	Names of the supported profiles	(implementation-dependent)
java.version	Java Runtime Environment version	"1.8"
java.vendor	Java Runtime Environment vendor	(implementation-dependent) e.g.: "Oracle Corporation"
java.vendor.url	Java vendor URL	(implementation-dependent) e.g.: "http://java.oracle.com/"
os.name	Operating system name	(implementation-dependent) e.g.: "Linux"
os.arch	Operating system architecture	(implementation-dependent) e.g.: "x86_64"
os.version	Operating system version	(implementation-dependent)
line.separator	Line separator	(implementation-dependent) e.g.: "\n" on UNIX
user.dir	Current working directory	(implementation-dependent)
java.io.tmpdir	Default temp file path	(implementation-dependent)

The property microedition.encoding describes the default character encoding name. This information is used by the system to find the correct class for the default character encoding in supporting internationalization. Property microedition.platform characterizes the host platform or device. Property microedition.configuration describes the current Java ME configuration and version, and property microedition.profiles defines a string containing the names of the supported profiles separated by blanks.

Note that the set of properties defined above can be extended by Java ME profile specifications or device manufacturers. For instance, the ME Embedded Profile 8 Specification [MEEP 8] defines additional properties not included above.

Manufacturer-specific property definitions should be prefixed with the same package name that the manufacturer-specific classes use (e.g., " com.companyname.propertyname "). The " microedition " namespace, as well as the " java " and " javax " namespaces are reserved, and may only be extended by official JCP approved specifications.