In December of 1998, Sun introduced the name "Java 2" (J2) to coincide with the release of Java 1.2. This new naming convention applies to all editions of Java, Standard Edition (J2SE), Enterprise Edition (J2EE), and Micro Edition (J2ME).

More on J2ME specification and explanation can be found at the microjava developer website and Billy Day’s website.

To support the broad range of products that fit within the scope of J2ME, Sun introduced the Configuration. A Configuration defines a Java platform for a broad range of devices. A Configuration is closely tied to a Java Virtual Machine (JVM). In fact, a Configuration defines the Java language features and the core Java libraries of the JVM for that particular Configuration.

The dividing line as to what a Configuration applies is for the most part based on the memory, display, network connectivity (or limitations of) and processing power available on a device.

The J2ME platform is defined for consumer devices (like Mobile phones, PDAs, set-top-boxes etc) with limited processing power when compared to desktops or servers. Hence, it incorporates decriptions for devices that are ouside the scope of J2SE and J2EE. However, even these limited consumer devices can be quite different from one another based on functionality, processing power, hardware capabilities and connnectivity. Hence a further differentiation is required to accomodate the broad range of consumer electronic and embedded devices. This modularity is achieved through configurations and profiles.

A J2ME configuration defines the minimum required java platform for the given electronic device. Thus, the configuration specifies the system level facilities available for programmers, java language features and the specifications of the virtual machine implemented.

A J2ME profile defines the application level interfaces for a given family of devices. A profile is implemented on top of a given configuration as an extension to it. It provides the libraries for a developer to write applications for the given device type.

Two configurations currently defined based on device characteristics are Connected, Limited Device Configuration (CLDC) and Connected Device Configuration (CDC). These two J2ME configurations are designed around different target device footprints. CLDC is designed for very small memory scenarios, typically 128 KB to 512 KB while CDC is designed for more moderate memory scenarios, typically 2 MB of RAM and 2.5 MB of ROM. As a result, the CLDC APIs are very compact and do not require J2SE compatibility. CDC is based on J2SE compatibility for both APIs and tools.

CLDC is the standard platform for small, resource limited, connected devices like mobile phones. A typical device would be characterized by 6 bit/16MHz or higher processor, 160-512 KB memory available for java platform, limited power (often battery operated) and with limited bandwidth connectivity.

CLDC specifies the core libraries and virtual machine features for J2ME implementations on resource-constrained devices. Sun provides the CLDC reference implementation (RI) which includes the K (kilobyte) virtual machine (KVM). KVM is a java virtual machine that provides the basis for the CLDC RI.

CLDC 1.1 (JSR 139) is a revised version of CLDC 1.0 (JSR 30) including new features (like floating point and weak reference support) but backward compatible with CLDC 1.0.

To address the broad range of capabilities, and to provide for more flexibility as technology changes, Sun introduced the concept of a Profile to the J2ME platform. A Profile is a set of APIs (designed for a specific configuration) that address the needs of a narrower device category.

A Profile is an extension, if you will, to a Configuration. It provides the libraries for a developer to write applications for a particular type of device. For example, the Mobile Information Device Profile (MIDP) defines APIs for user interface components, input and event handling, persistent storage, networking and timers, taking into consideration the screen and memory limitations of mobile devices.

A few common profiles are listed below:

Foundation Profile, Personal profile (JSR-62), RMI (Remote method invocation) profile (JSR-66) etc...

An explanation on J2ME profiles can be found here.

Mobile Information Device Profile (MIDP)

MIDP is the standard API for java application development. MIDP, combined with the Connected Limited Device Configuration (CLDC), is the Java runtime environment for today's mobile information devices (MIDs) such as phones and entry level PDAs. What MIDP provides is the core application functionality required by mobile applications - including the user interface, network connectivity, local data storage, and application lifecycle management - packaged as a standardized Java runtime environment and set of Java technology APIs.

Versions:

MIDP 1.0 has APIs for application lifecycle, HTTP network connectivity, user interface and persistent storage.

MIDP 2.0 has enhancements in secure networking (HTTPS), multimedia, form &item enhancements, game API, OTA, permissions and code signing etc

MIDP 2.1 includes mobile service architecture (MSA) clarifications, enhanced security model and new domains.

There are various optional packages available which may not be associated with a specific configuration or profile (The following list is not exhaustive).

Devices implement a complete software stack which consists of a configuration, a profile and optional APIs. The first generation J2ME mobile phones usually implemented MIDP 1.0 over CLDC 1.0.

JTWI (JSR 185) mandates that the supported devices must have CLDC 1.0 or 1.1 along with MIDP 2.0 and WMA with optional MMAPI support. Hence, the developer has a clear understanding of what APIs will be available.

MSA is termed the successor of Java technology for wireless industry. It is the platform definition for the high volume wireless which enhances JTWI specifications with definitions of new technologies. To comply with MSA, an implementation must support all mandatory JSRs and all conditionally mandatory JSRs for the relevant implementation. For example, a device that claims support for Bluetooth wireless technology must support the Bluetooth API (JSR 82, which is not always required).

MSA Specifications

(Image Source: The MSA specification (JSR 248) Copyright 1994-2006 Sun Microsystems, Inc. All Rights Reserved. )

MSA Overview

(Copyright 1994-2006 Sun Microsystems, Inc. All Rights Reserved. )

MIDlet

A MIDlet is a java application that conforms to the specifications set out by the CLDC and the MIDP. The execution states of a MIDlet are defined as its life cycle: creation, start, pause and exit.

The application management software (AMS) is the software on a device that manages the downloading and life-cycles of MIDlets. The AMS can be device dependent software on the mobile device responsible for installing, running and removing MIDlets from the device. It can also provide optional features like error handling, start, stop and deletion of MIDlets.

Usually, all the files, classes and resources required by a MIDlet are packaged together into a single Java Archive file (JAR file with extension .jar). The contents of the JAR file is listed in a manifest file within the JAR archive.

Required attributes:

• MIDlet-Name
• MIDlet-Version
• MIDlet-Vendor
• MIDlet-Number for each MIDlet in the JAR
• Micro edition- Profile
• Micro edition- Configuration

The first prototype implementation of the Java virtual machine, done at Sun Microsystems, Inc., emulated the Java virtual machine instruction set in software hosted by a handheld device that resembled a contemporary Personal Digital Assistant (PDA). Sun's current Java virtual machine implementations, components of its Java TM 2 SDK and Java TM 2 Runtime Environment products, emulate the Java virtual machine on Win32 and Solaris hosts in much more sophisticated ways. However, the Java virtual machine does not assume any particular implementation technology, host hardware, or host operating system. It is not inherently interpreted, but can just as well be implemented by compiling its instruction set to that of a silicon CPU. It may also be implemented in microcode or directly in silicon.

The Java virtual machine knows nothing of the Java programming language, only of a particular binary format, the class file format. A class file contains Java virtual machine instructions (or byte codes) and a symbol table, as well as other ancillary information.

Java, since its inception, has grown into a hugely popular platform independent programming language. There are quite a few integrated development environments available for Java. Varying from simple editors with keywords highlighting to very professional IDEs, choosing one is a matter of personal preference. Popular IDEs include Eclipse, JBuilder, Sun Java Studio, Netbeans, JCreator etc.

The popularity of each of the various Java IDEs has tended to fluctuate in the race to provide new features, improve performance, and become easier to use. The most interesting new development has been the introduction of two free, extensible open source IDEs: Eclipse and Netbeans. These are rapidly approaching the capabilities of commercial offerings. Most developers won't need more than what these two excellent development platforms provide. They both have syntax checking, code completion, and code folding. They both let you compile, run, and debug your code. They both support Ant, CVS, and JUnit. Also, both now have integrated GUI builders.

Many programmers prefer Eclipse because of its ease of use; the overall design of Eclipse keeps the tools you need immediately at your fingertips. Many programmers also find Eclipse faster and more stable. However, the ultimate decision is up to the developer based on his preferences.

Eclipse is by far the most popular IDE (This is a generalized abstract statement, opinion of the author, personal choice etc; nothing against other IDEs!). A comparison of Java IDEs is available here and a list of free JAVA IDEs is available here.

A short discussion on how to acuire, install and start on Eclipse IDE is attempted here

References:

http://developers.sun.com/ ©2006 Sun Microsystems, Inc. All rights reserved. Sun, Sun Microsystems, the Sun logo, Java, J2ME, and Java Card are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries.

               
Migrating to Eclipse: A developer's guide to evaluating Eclipse vs. Netbeans, Why you should consider Eclipse and how it differs from Netbeans; Level: Introductory, David Gallardo (david@gallardo.org), Software consultant, 08 Sep 2004

In-depth Venture into Sun Java Wireless Toolkit 2.5 for CLDC by Richard Gregor

Disclaimer: The information provided on this page comes without any warranty whatsoever and the author is not responsible for the content of external websites. Use it at your own risk. Just because a program, book or service is listed here or has a good review does not mean that we endorse or approve of the program or of any of its contents. All the other standard disclaimers also apply.