J2ME Core Concepts

Forum for J2ME mobile games related topics including programming doubts, books and other resources for J2ME game development

J2ME Core Concepts

Postby DevelopmentTeam » Wed Aug 16, 2006 7:45 am

At the heart of Java 2 Micro Edition (J2ME) are three core concepts: configurations, profiles, and optional packages. You can't write a J2ME application without understanding these concepts, because they determine the features of Java that you can use, which application programming interfaces (APIs) are available, and how your applications are packaged.

ConfigurationsA configuration is a complete Java runtime environment, consisting of three things:

A Java virtual machine (VM) to execute Java bytecode.
Native code to interface to the underlying system.
A set of core Java runtime classes.
To use a configuration, a device must meet certain minimum requirements as defined in the configuration's formal specification. Although a configuration does provide a complete Java environment, the set of core classes is normally quite small and must be enhanced with additional classes supplied by J2ME profiles or by configuration implementor. In particular, configurations do not define any user interface classes.

J2ME defines two configurations, the Connected Limited Device Configuration (CLDC) and the Connected Device Configuration (CDC). The CLDC is for very constrained (limited) devices -- devices with small amounts of memory and/or slow processors. The VM used by the CLDC omits important features like finalization, while the set of core runtime classes is a tiny fraction of the J2SE core classes, just the basics from the java.lang, java.io and java.util packages, with a few additional classes from the new javax.microedition.io package. The CDC, on the other hand, includes a full Java VM and a much larger set of core classes, so it requires more memory than the CLDC and a faster processor. The CDC is in fact a superset of the CLDC. We'll discuss the configurations in detail in the next two articles in this series.

A profile adds domain-specific classes to a configuration to fill in missing functionality and to support specific uses of a device. For example, most profiles define user interface classes for building interactive applications.

To use a profile, the device must meet all the minimum requirements of the underlying configuration as well as any additional requirements mandated by the profile's formal specification.

There are several profiles in various stages of development. The first profile to be released was the Mobile Information Device Profile (MIDP), a CLDC-based profile for running applications on cellphones and interactive pagers with small screens, wireless HTTP connectivity, and limited memory. Another CLDC-based profile under development is the Personal Digital Assistant Profile (PDAP), which extends MIDP with additional classes and features for more powerful handheld devices. In terms of CDC-based profiles, the Foundation Profile (FP) extends the CDC with additional J2SE classes, the Personal Basis Profile (PBP) extends the FP with lightweight (AWT-derived) user interface classes and a new application model, and the Personal Profile extends the PBP with applet support and heavyweight UI classes. We'll also be discussing these profiles later on in this series.

Optional Packages
An optional package is a set of APIs in support of additional, common behaviors that don't really belong in one specific configuration or profile. Bluetooth support, for example, is defined as an optional package. Making it part of a profile wouldn't work, because none of the behaviors of a profile can be optional -- if a device supports a profile, it must support the entire profile -- and that would limit the profile to Bluetooth-enabled devices.

Optional packages have their own minimum requirements, of course, just like configurations and profiles. Optional packages also have specific dependencies on a particular configuration and/or one or more profiles -- they do not define a complete runtime environment, just sets of related APIs.

There are many optional packages in development, including the RMI Optional Package, which adds RMI support to CDC/FP-based profiles, the Java APIs for Bluetooth, which adds Bluetooth support to CLDC-based profiles, and the JDBC Optional Package for CDC/Foundation Profile, which defines a subset of JDBC (database access APIs) for use with CDC/FP-based profiles. Again, we'll be covering these later on in the series as the need arises.

The KVM and CVM
Two other terms you'll see mentioned in J2ME literature are KVM and CVM. These are the names of Java virtual machines for the CLDC (KVM) and the CDC (CVM), written specifically to work in the constrained environment of a handheld or embedded device and to be easily ported to different platforms. It should be noted, however, that the CLDC and CDC specifications do not require the use of the KVM or the CVM, only the use of a VM that adheres to the requirements of the specification in question. While many device manufacturers license the KVM or CVM from Sun Microsystems to serve as the core of their J2ME implementation, they are not required for J2ME compliance. It is a mistake, therefore, to consider the CLDC and KVM as synonymous, and similarly for the CDC and the CVM.

What It All Means
It should now be apparent that "J2ME application" is an ambiguous term. For what profile is the application intended? Which optional packages does it require? How much memory does it take? These are the questions you must ask yourself before you start application development, because they determine which language features and which classes your application can use. If you limit your application to CDC-based profiles, for example, you make development simpler of the many familiar J2SE APIs, but you cut out the low-end devices from your potential install base. Targeting CLDC-based profiles, on the other hand, makes your development task harder, especially when trying to shrink the size of your application to run on as many of the smaller devices as possible. These are the kinds of tradeoffs you'll have to make as you begin to work with J2ME. The information in this series will help you decide what's really important.
User avatar
Site Admin
Posts: 661
Joined: Tue Aug 15, 2006 8:39 am
Location: India

Postby DevelopmentTeam » Wed Aug 16, 2006 7:49 am

At the core of Java 2 Micro Edition (J2ME) are the configurations, the specifications that define the minimal feature set of a complete Java runtime environment. J2ME currently defines two configurations. In this article we look at the first of these, the Connected Limited Device Configuration, or CLDC for short.

The CLDC Specification
Like all J2ME technology, the CLDC is defined by a specification that has passed through the Java Community Process (JCP). At this time, there are two versions of the CLDC. Version 1.0, released in May of 2000, is known as Java Specification Request (JSR) 30. Version 1.1, currently in public review, is JSR 139. Because version 1.0 is the one that is currently shipping in devices, we'll concentrate on it.

The CLDC specification defines three things:

The capabilities of the Java virtual machine (VM), which is not a full-featured Java VM.
A very small subset of the J2SE 1.3 classes.
A new set of APIs (application programming interfaces) for input/output called the Generic Connection Framework.
It's also important to understand what the CLDC does not define. The CLDC does not define any APIs related to user interfaces. The CLDC does not define how applications are loaded onto a device or how they are activated or deactivated. These and other things are defined by the J2ME profiles that use the CLDC as their base. So while it's true that the CLDC does define a complete Java runtime environment, the additional APIs defined by a profile or supplied by the vendor are really necessary to build useful applications.

The Virtual Machine
The Java VM used in the CLDC is restricted in certain important ways when compared to a full-featured J2SE VM. These restrictions allow the VM to fit the memory and power constraints of the small devices that the CLDC target: the CLDC VM and classes can fit in 128K of memory.

The primary restrictions on the VM are:

No floating point types.
No object finalization or weak references.
No JNI or reflection (hence no object serialization).
No thread groups or daemon threads (note that threads are supported, just not thread groups).
No application-defined class loaders.
Note that CLDC 1.1 relaxes some of these restrictions, in particular reenabling support for floating point types and weak references.

In addition to the above restrictions, the CLDC also requires class verification to be done differently. Class files are processed by an off-device class verifier, a process called preverification. At runtime, the VM uses information inserted into the class files by the preverifier to perform the final verification steps. Files that have not been processed by the preverifier are not loaded since they cannot be verified.

The J2SE Subset
The subset of J2SE 1.3 included in the CLDC consists of classes from these three packages:

Only selected classes from each package are included: for example, the java.util.Vector and java.util.Hashtable classes are included, but none of the collection classes are. The largest package is the java.lang package, which defines the classes that are fundamental to any java application, classes like java.lang.Object or java.lang.Integer. The java.io subset only includes abstract and memory-based classes and interfaces like java.io.DataInput or java.io.ByteArrayInputStream. The java.util subset only includes a few utility classes.

Some of the classes are subsets of their J2SE equivalents. Configurations are allowed to remove unnecessary methods or fields, but they cannot add new public or protected methods.

The Generic Connection Framework
J2SE includes many classes for performing input and output, classes that are found in the java.io and the java.net packages. Unfortunately, there are a large number of I/O classes and they tend to encapsulate I/O models that are not necessarily found on all devices. For example, some handheld devices do not have file systems. Socket support is not universal, either.

What the CLDC has done, then, is to define a new set of APIs for I/O called the Generic Connection Framework. The GFC, part of the new javax.microedition.io package, defines interfaces for the different kinds of I/O that are possible and a factory class for creating objects that implement those interfaces. The type of object to create is specified in the protocol part of the URL (universal resource locator) passed to the factory class.

For example, a socket connection can be made using code like this:

import java.io.*;
import javax.microedition.io.*;

StreamConnection conn = null;
InputStream is = null;
String url = "socket://somewhere.com:8909";

try {
conn = (StreamConnection) Connector.open( url );
is = conn.openInputStream();
.... // etc. etc.
catch( ConnectionNotFoundException cnfe ){
// handle it
catch( IOException e ){
// handle it
finally {
if( is != null ) try { is.close(); } catch( Exception e ){}
if( conn != null ) try { conn.close(); } catch( Exception e ){}

The code above assumes that the device knows how to map the "socket" protocol in the URL to an object that implements the GCF's StreamConnection interface, which defines methods for obtaining the input and output streams of a socket connection. It should be noted, however, that the CLDC does not actually define any I/O implementations. In other words, the CLDC defines the interfaces of the GCF, but the implementation classes -- the ones that do the actual I/O -- are left to the profiles and/or the device vendor to define. For example, the Mobile Information Device Profile (MIDP) -- a CLDC-based profile -- requires support for a subset of HTTP 1.1 and so it recognizes the "http" protocol in URLs and returns objects that implement the GCF's ContentConnection interface.

Using the CLDC
By itself, the CLDC is a limited programming platform. Because it does not define any user interface classes or implement any I/O models, about all you can do for output is write to the System.out stream, which may or may not be captured to a console or file. You really need the extra classes defined by a J2ME profile (like those of the MIDP) or device-specific classes (like those on the RIM BlackBerry devices or certain Japanese i-Mode phones) to do anything interactive.

If you're still interested in trying out the CLDC, Sun has a reference implementation hosted on Windows or Solaris available for download from its website. This reference implementation includes the preverify offline verification utility as well as a CLDC VM and the CLDC runtime classes. See Sun's main CLDC page for links to it and to the CLDC specification. You can also use toolkits or integrated development environments like Sun's J2ME Wireless Toolkit, Metrowerks' CodeWarrior Wireless Studio, or Borland's JBuilder MobileSet to explore CLDC programming.[/b]
User avatar
Site Admin
Posts: 661
Joined: Tue Aug 15, 2006 8:39 am
Location: India

Postby DevelopmentTeam » Wed Aug 16, 2006 7:51 am

The second configuration at the core of Java 2 Micro Edition (J2ME) is the Connected Device Configuration, or CDC for short.The CDC is a superset of the Connected Limited Device Configuration (CLDC). It provides a much more conventional Java 2 runtime environment.

The CDC Specification
Like the CLDC (see my previous article, The Connected Limited Device Configuration (CLDC)), the CDC is defined by a specification that has passed through the Java Community Process (JCP). The CDC, known as Java Specification Request (JSR) 36, was released in March 2002.

The CDC specification is a much smaller document than the CLDC specification because the CDC is much closer to a Java 2 Standard Edition (J2SE) runtime environment than the CLDC. The CDC specification defines four things in particular:

The capabilities of the Java virtual machine (VM). Unlike the CLDC, the CDC VM is a full-featured VM.
A subset, much larger than the CLDC's, of the J2SE 1.3 classes.
The same APIs (application programming interfaces) that are new to the CLDC -- in other words, the Generic Connection Framework (GCF).
Support for file- and datagram-based input/output using both the GCF and the familiar java.io and java.net classes.
Note that, just like the CLDC, the CDC does not define any user interface classes or how applications are loaded and activated: these are left for the profiles to define.

The Virtual Machine
The CDC supports a complete, full-featured Java 2 virtual machine (VM) as defined in The Java Virtual Machine Specification. The low-level interfaces for calling native code, connecting to debuggers, and profiling code are optional, but if supported they must be the standard interfaces -- Java Native Interface (JNI), Java Virtual Machine Debugging Interface (JVMDI), and Java Virtual Machine Profiling Interface (JMVPI) -- used in Java 1.3.

Note that the CDC does not require preverification of classes, as full class verification is done on the device by the VM. Classes that have been preverified can also be used, of course, since the additional information added to the class files by the preverifier is ignored.

Because the VM is full-featured, and there are more classes, the minimum memory footprint for the CDC is larger than the CLDC's: the device needs at least 512K for the runtime environment, plus at least 256K to hold and run applications.

The J2SE Subset
The subset of J2SE 1.3 included in the CDC consists of classes from these packages:

As you can see, the CDC includes many more packages than the CLDC, and many more classes even in the shared packages. For example, the CDC includes the collections classes from the java.util package, while the CLDC does not. This makes the CDC a much more J2SE-like environment than the CLDC. There are still classes missing, of course. For example, the java.net package as defined by the CDC only includes the classes related to datagram sockets, not stream sockets.

The Generic Connection Framework
Since the CDC is a superset of the CLDC, it includes the Generic Connection Framework (GCF). Unlike the CLDC, however, the CDC also requires GCF support for two specific connection types: files and datagrams. This makes sense because the CDC includes the file classes from the java.io package and the datagram classes from the java.net package. It is therefore straightforward for the device manufacturer to write GCF implementation classes that simply map GCF requests (using the file or datagram protocol at the start of a URL) into their java.io and java.net equivalents.

File and Datagram Support
Here is an example of opening a file for writing using the GCF:

import java.io.*;
import javax.microedition.io.*;

try {
String url = "file:/logs/mylog.txt";
OutputConnection conn =
(OutputConnection) Connector.open( url,
Connector.WRITE );
OutputStream out = conn.openOutputStream();
..... // write to the output stream
catch( IOException e ){
// handle error

Datagram support is a bit more complex, but quite similar.

Why not just use the java.io and java.net classes directly? The GCF provides a consistent I/O model that works across all J2ME platforms that support the required protocols. If you don't need interoperability with J2SE, use the GCF whenever possible to open your I/O connections.

Using the CDC
Like the CLDC, the CDC is by itself a limited programming platform. Again, because it does not define any user interface classes or implement any I/O models, about all you can do for output is write to the System.out stream, which may or may not be captured to a console or file. The extra classes defined by one or more J2ME profiles are really required to write interactive applications.

Sun has a reference implementation of the CDC hosted on Linux available for download from its website. See Sun's main CDC page for links to it and to the CDC specification.
User avatar
Site Admin
Posts: 661
Joined: Tue Aug 15, 2006 8:39 am
Location: India

Postby DevelopmentTeam » Wed Aug 16, 2006 7:53 am

Although configurations are at the heart of Java 2 Micro Edition (J2ME), it's the profiles that are of real interest. Profiles define the application programming interfaces (APIs) that are required to write useful applications for a particular group or family of J2ME devices. The Mobile Information Device Profile (MIDP) defines a Java runtime environment for cellphones, interactive pagers, and similar mass-produced, resource-constrained handheld devices.

Mobile Information Devices
MIDP is targeted at a class of devices known as mobile information devices (MIDs). These are devices that have the following minimal characteristics:

Enough memory to run MIDP applications (see below)
A bit addressable display at least 96 pixels wide by 56 pixels high, either monochrome or color.
A keypad, keyboard, or touch screen.
Two-way wireless networking capability.
Almost any wireless device built these days fits the definition of a MID, including low-end cellphones. Personal digital assistants (PDAs) can also be considered to be MIDs because wireless networking is now an option for most PDAs, but MIDP doesn't target these devices specifically: PDAs have more memory, larger screens, and interesting information management capabilities that are more effectively exploited using other profiles.

The MIDP Specification
There are two versions of the Mobile Information Device Profile, both defined using the Java Community Process (JCP). MIDP 1.0, known as Java Specification Request (JSR) 37, was released in September 2000. MIDP 2.0, JSR 118, is currently in proposed final draft form, the final step before formal release as a final specification. No devices yet support MIDP 2.0, but there are many devices currently on the market that support MIDP 1.0. We'll concentrate solely on MIDP 1.0 for now, deferring discussion of MIDP 2.0 until later in this series.

The MIDP 1.0 specification was defined by an expert group consisting of all the major players in the wireless and handheld device arena, including familiar names like Motorola, Nokia, Ericsson, Research in Motion, and Symbian. It has a lot of support in the telecommunications industry, and handset manufacturers like Motorola and Nokia in particular are devoting a lot of development effort to supporting MIDP in a wide range of their devices.

The configuration used by MIDP is the Connected Limited Device Configuration (CLDC), which we've already discussed in a previous article in this series. The CLDC has the small footprint required to run on low-end devices. Devices that are capable of running the other configuration, the Connected Device Configuration (CDC), can also run MIDP, of course, since the CDC is a superset of the CLDC.

The MIDP adds APIs in a number of areas to the very basic APIs defined by the CLDC. The new features include:

Support for application lifecycle management similar to the way applets are defined in Java 2 Standard Edition.
Persistent storage of data.
HTTP-based network connectivity based on the CLDC's Generic Connection Framework.
Simple user interface support, with enough flexibility to build games or business applications.
The MIDP specification is silent about a number of things, however. For example, in MIDP 1.0 there is no standard way to interface to the device's phonebook, if it has one, in order to initiate voice calls. There are no standard facilities for data synchronization, even if the device supports the feature. Device manufacturers can and do provide their own device-specific APIs for these kinds of features, though, but using them limits your application's portability.

Note that the MIDP specification is particularly silent in one area: how MIDP applications are loaded onto a device and how they are activated or deactivated. As such, different devices will do these in different ways. The MIDP specification basically concerns itself with what the application does once it's running, not how it's activated.

MIDlets and MIDlet Suites
As mentioned, MIDP defines an application lifecycle model similar to the applet model. In fact, MIDP does not support the running of traditional applications that use a static main method as their entry point. Nor can MIDP applications call the System.exit method in order to terminate. MIDP applications must follow specific packaging rules.

A MIDP application is referred to as a MIDlet. Its entry point is a class that extends the javax.microedition.midlet.MIDlet class, much in the same way that an applet extends the java.applet.Applet class. This class is referred to as the MIDlet's main class. The MIDlet class defines abstract methods that the main class implements: these methods are called by the system to notify the MIDlet that its state is changing. For example, whenever the MIDlet is being activated its startApp method is called. Again, this is very similar to the way applets behave.

Here is the code for a very basic MIDlet, drawn from Chapter 3 of Mobile Information Device Profile for Java 2 Micro Edition:

// A trivial MIDlet
package com.developer.j2me;

import javax.microedition.lcdui.*;
import javax.microedition.midlet.*;

public class MyMIDlet extends MIDlet
implements CommandListener {

private Display display;
private Command exitCommand = new Command( "Exit",
Command.EXIT, 1 );

// Constructor, doesn't do anything really

public MyMIDlet(){
System.out.println( "MyMIDlet constructed" );

// Called when the system is destroying the MIDlet.

protected void destroyApp( boolean unconditional )
throws MIDletStateChangeException {

// Called when the system is pausing the MIDlet.

protected void pauseApp(){
System.out.println( "MyMIDlet paused" );

// Called when the system is activating the MIDlet.

protected void startApp() throws MIDletStateChangeException {
if( display == null ){ // first time called...

System.out.println( "MyMIDlet started" );

// Called to initialize the MIDlet. Executes only
// once. Obtains the Display instance associated
// with this MIDlet and creates a simple
// user interface for it.

private void initMIDlet(){
display = Display.getDisplay( this );
display.setCurrent( new TrivialForm() );

// Called to exit the MIDlet. Centralizes all the
// cleanup work.

public void exitMIDlet(){
System.out.println( "MyMIDlet destroyed" );

// Event handling. Called by the system when the
// user activates a command, normally by pressing
// a button.

public void commandAction( Command c, Displayable d ){

// A trivial UI screen. A titled blank screen
// to which a single command is associated. The system
// will map that command to a button or a menu item.

class TrivialForm extends Form {
super( "MyMIDlet" );
addCommand( exitCommand );
setCommandListener( MyMIDlet.this );

One or more MIDlets are packaged together into what is referred to as a MIDlet suite, which is basically a standard JAR (Java archive) file and a separate file called an application descriptor. All the user-defined classes required by the suite's MIDlets must be in the JAR file, along with any other resources (such as images) that the MIDlets require. The JAR file must also include a manifest with a number of MIDP-specific entries that describe the MIDlets in the suite. The application descriptor contains similar information, and is used by devices to obtain information about a MIDlet suite without having to download and install the MIDlet suite first.

Here is an example of the manifest that goes along with the simple MIDlet shown above:

MIDlet-1: MyMIDlet, MyMIDlet.png, com.developer.j2me.MyMIDlet
MIDlet-Name: MyMIDlet
MIDlet-Vendor: Eric Giguere
MIDlet-Version: 1.0
MicroEdition-Configuration: CLDC-1.0
MicroEdition-Profile: MIDP-1.0

And here is an example of an application descriptor for the same MIDlet:

MIDlet-1: MyMIDlet, MyMIDlet.png, com.developer.j2me.MyMIDlet
MIDlet-Jar-Size: 4238
MIDlet-Jar-URL: http://somewhere.foo.com/MyMIDlet.jar
MIDlet-Name: MyMIDlet
MIDlet-Vendor: Eric Giguere
MIDlet-Version: 1.0

These are only examples, of course, and we'll be discussing these in more detail as the series progresses.

Developing MIDP Applications
As the first J2ME profile to be released and to ship commercially, there are actually several MIDP programming tools available, often as add-ins for your favorite Java development environment. A development environment is not enough, however.

The reality of MIDP programming today is that the applications you can write are constrained in many ways. These constraints often require you to think about things that you wouldn't think of twice of with J2SE programming. Memory is a particularly scarce resource, for example. The early Motorola J2ME-enabled phones limited the size of a MIDlet suite to 50K (since raised to 100K on more recent models) and some Nokia phones limit them to even less, about 30K. Because MIDP 1.0 applications cannot share classes between suites, this really limits what you can do on the device. You'll find that placing part of your application in a web or application server (as a servlet, typically) that the MIDP application calls is almost a requirement for anything serious. This will change over time, of course, as memory limits are eased in newer devices.
User avatar
Site Admin
Posts: 661
Joined: Tue Aug 15, 2006 8:39 am
Location: India

Return to J2ME Games

Who is online

Users browsing this forum: No registered users and 1 guest