This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
Java is a programming language originally developed by James Gosling at Sun Microsystems, which is now a subsidiary of Oracle Corporation. It was released in 1995 as a core component of Sun Microsystems' Java platform. Java is general-purpose, concurrent, class-based, and object-oriented, and is specifically designed to have as few implementation dependencies as possible. It is intended to let application developers "write once, run anywhere".
Recognizing that "one size doesn't fit all", Sun has defined and supports four editions of Java aiming different application environments and segmented many of its APIs so that they belong to one of the platforms. The platforms are:
Java Card - aimed for smartcards.
Java Platform, Micro Edition (Java ME) - aimed at small and memory constrained devices by means of environments with limited resources.
Java Platform, Standard Edition (Java SE) - aimed at standard desktop and workstation environments.
Java Platform, Enterprise Edition (Java EE) - aimed at heavy duty server systems, large distributed enterprise or Internet environments.
Java ME was formerly known as Java 2 Platform Micro Edition (J2ME), is a Java platform designed for mobile devices and embedded systems. Java ME technology was originally created in order to deal with the constraints associated with building applications for small devices with as little as 128KB of RAM and with processors a lot less powerful than those used on typical desktop and server machines. Thus, Sun defined the basics for Java ME technology to fit such a limited environment and make it possible to create Java applications running on small devices with limited memory, display and power capacity.
There are three core concepts in the Java ME technology:
Configuration - provides the most basic set of libraries and virtual machine capabilities for a broad range of devices.
Profile - set of APIs that support a narrower range of devices.
Optional package - set of APIs in support of additional, common behaviours that don't really belong in one specific configuration or profile
J2ME consists of a set of profiles. Each profile is defined for a particular type of device and consists of a minimum set of class libraries required for the particular type of device and a specification of a Java virtual machine required to support the device. A profile itself does not do anything; it just defines the specification. Since profiles are subsets of configurations, profiles are implemented with a configuration. Ultimately, Java ME platform has been divided into two base configurations which is Connected Device Configuration (CDC) and Connected Limited Device Configuration (CLDC).
Java ME was designed to use profiles and configurations to enables devices of varying ability to able to run Java ME applications on the Kilobytes Virtual Machine (KVM), which is the micro version of Java Virtual Machine (JVM). Figure 1 illustrates how the CDC and the CLDC together make Java ME. The diagram also shows an overview of the components of Java ME architecture, and how it fits in the overall Java model.
Figure 1: Java ME Architecture
Configuration is a preliminary Java platform for devices with similar requirements with respect to total memory, processing speed, power and display constraints. Specifically, a configuration consists of Java language features, JVM features and a limited set of generalized APIs. Configurations are closely linked with JVM. In fact, configuration is a term identifying Java language features as a set of APIs and a specific JVM for that particular configuration. The dividing line as to what configuration applies to a device is for the most part, dependent on the memory, processing power, network connectivity and display constraints of a device.
There are currently two configurations available, each optimized for a particular horizontal device family having similar capabilities:
Connected Limited Device Configuration
An implementation of MIDP for small mobile, resource-constrained devices.
Connected Device Configuration
An implementation of the Foundation Profile for next-generation, more capable mobile and embedded devices.
Table 1: Comparison between CDC and CLDC
Connected Limited Device Configuration (CLDC).
The Connected Limited Device Configuration (CLDC) is a fundamental part of the architecture of the Java ME that targeting resource-constraint devices like mobile phones. It is specifically designed to meet the needs for a Java platform to run on devices with limited memory, processing power and graphical capabilities. CLDC contains a strict subset of the Java-class libraries, and is the minimum amount needed for a Java virtual machine to operate. CLDC is basically used to classify myriad devices into a fixed configuration. When coupled with one or more profiles, the CLDC gives developers a solid Java platform for creating applications for consumer and embedded devices.
CLDC is designed to bring the many advantages of the Java platform to network-connected devices that have limited processing power, memory, and graphical capability. Target devices typically have the following capabilities:
A 16-bit or 32-bit processor with a clock speed of 16MHz or higher.
At least 160 KB of non-volatile memory.
At least 192 KB of total memory available for the Java platform.
Low power consumption, often operating on battery power.
Connectivity to some kind of network, often with a wireless, intermittent connection and limited bandwidth.
On top of the different configurations Java ME platform also specifies a number of profiles defining a set of higher-level APIs that further define the application. A widely adopted example is to combine the CLDC with the Mobile Information Device Profile (MIDP) to provide a complete Java application environment for mobile phones and other devices with similar capabilities.
Connected Device Configuration (CDC)
CDC is a specification of a framework for Java ME applications describing the basic set of libraries and virtual-machine features that must be present in an implementation. The targets for CDC-based technology comprise a broad range of consumer and embedded devices like smart communicators, pagers, high-end personal digital assistants (PDAs), and set-top boxes. Within this range, CDC is the basis for several standard API bundles that address the needs of developers of applications for specific categories of devices.
Devices that support CDC typically include a 32-bit microprocessor/controller and make about 2 MB of RAM and 2.5 MB of ROM available to the Java application environment. The CDC configuration was designed to bring the many advantages of the Java platform to a broad range of network-connected consumer and embedded devices.
CDC versus CLDC
The CLDC is different from, yet also a subset of the CDC. The two configurations are independent of each other, however, so they should not be used together to define a platform. The CLDC is a proper subset of the CDC. Neither the CLDC nor the CDC is a proper subset of the J2SE platform, however, because both of these configurations add new classes necessary to deliver services on their respective families of devices. Like the CDC, the CLDC specifies the level of support of the Java programming language required, the required functional support of a compliant Java VM, and the set of class libraries required. Figure 2 shows the relationship between the two configurations and the J2SE platform.
Figure 2: Relation of CLDC with CDC and J2SE
Profiles are an extension of its underlying configuration. A profile simply is a set of APIs but unlike configurations, profiles are closer and specific to the target device capabilities. They are intended to include device specific APIs providing those functionality missing at configuration level such as user interface, persistence, etc. Profiles obtain the required foundation from configuration and hence are layered above configurations.
Currently, there are a handful profiles available and a few more are being finalized. MIDP is a profile supported by CLDC while CDC support three different profiles namely the Foundation Profile (JSR 219), Personal Basis Profile (JSR 217) and Personal Profile (JSR 216).
Foundation Profile (FP)
Foundation Profile is the most basic of the CDC family of profiles. It is a skeleton upon which a developer can create a new profile. The FP APIs, together with CDC APIs provides a complete Java ME JRE for consumer electronics and embedded devices. It is a set of Java APIs tuned for low-footprint devices that have limited resources that do not need a graphical user interface system. It provides a complete Java ME application environment for consumer products and embedded devices but without a standards-based GUI system. Version 1.1.2 is specified in JSR 219 and implements a subset of Java SE 1.4.2, including a set of security-related optional packages, such as Java Authentication and Authorization Service (JAAS), Java Secure Socket Extension (JSSE), and Java Cryptography Extension (JCE).
The Mobile Information Device Profile (MIDP)
The Mobile Information Device Profile (MIDP), combined with the Connected Limited Device Configuration (CLDC), is the Java runtime environment for today's mobile information devices such as phones and entry level PDAs. MIDP provides the core application functionality required by mobile applications - including the user interface, network connectivity, local data storage, and application lifecycle management.
Currently, there are three version of MIDP which are MIDP 1.0, MIDP 2.0 and MIDP 3.0. With the configuration and profiles, the actual application then resides, using the different available APIs in the profile.
Following in the tradition of Java parlance, MIDP applications are called MIDlets. A MIDlet is a Java application that uses the MIDP profile and the CLDC configuration, created by a Java ME software developer, such as a game, a business application or other mobile features. These MIDlets can be written once and run on every available device conforming to the specifications for Java ME technology. The MIDlet can reside on a repository somewhere in the ecosystem and the end user can search for a specific type of application and having it downloaded over the air to another device.
2.1.4 Kilobyte Virtual Machine (KVM)
The Kilobyte virtual machine (KVM) is a virtual machine derived from the Java Virtual Machine (VM) specification. The VM that comes with the CLDC reference implementation is called the Kilobyte Virtual Machine (KVM) because it uses only a few kilobyte of runtime memory as opposed to megabyte. It is a reference implementation that adheres to the CLDC specification's description of a compliant VM. It is designed for small devices as it has a small memory footprint. It supports a subset of the features of the higher end JVM.
For low-end, resource-limited products, Java ME and the KVM support minimal configurations of the Java virtual machine and Java APIs that capture just the essential capabilities of each type of device. KVM can be deployed flexibly to address a range of trade-offs between space and functionality. The KVM is engineered and specified to support the standardized, incremental deployment of the Java virtual machine features and the Java APIs included in the Java ME architecture