Chapter 1:

Let’s Start

· Java Benefits for wireless devices

· J2ME, J2SE and J2EE

· Configurations and Profiles

· The MID Profile

· The KVM

· Writing the first MIDlet

· J2ME (CLDC\MIDP) comparing to the J2SE

Java b enefits for wireless devices

Java is ideally suited to become the standard application development language for wireless devices, providing us with lots of benefits. Hereto some of the most important ones:

Cross platform compatibility

The Java application can easily transferred between different devices and different platforms as long as the JVM\KVM has been developed for those devices.

Object Oriented Programming

Java has a better abstraction mechanisms and higher level programming constructs than C++.

Huge java developer community

Java has become the most popular programming language taught in schools and universities.

Security

Java is known for its security features (class file verification, cryptography possibilities etc...)

Dynamic

Java classes can easily downloaded dynamically over the network, and easily integrated with the running application.

J2ME, J2SE and J2EE

Sun Microsystems has grouped the Java Technologies into three editions that aimed at the specific areas of today’s software industry:

Java 2 Platform, Enterprise Edition (J2EE) for enterprises needing scalable server solutions.

Java 2 Platform, Standard Edition (J2SE) for the personal computer (desktop).

Java 2 Platform, Micro Edition (J2ME) for small devices such as: PDA’s, mobile telephones, pagers, consumer devices etc…

Each Java Platform edition defines a set of technologies:

JVM

Libraries of classes\API’s

Tools for development

The following figure illustrates the Java 2 Platform editions and their target markets.

The J2ME has two configurations:

CDC (Connected Device Configuration)

and

CLDC (Connected, Limited Device Configuration)

These two configurations target two categories of products:

High-end devices (TV set-top boxes, Internet TVs, automobile navigation systems etc…) which have large range of user interface capabilities, high-bandwidth network connections (usually TCP/IP) and more memory and CPU power.

and

Low-end devices (Cell phones, pagers, PDA’s etc…) which have very simple user interface and small screen size, less memory, less CPU power, lower bandwidth and most of them are usually operated using batteries.

Configurations and Profiles

Using the configurations and the profiles the J2ME platform can be expanded and customized as needed.

Configuration

A J2ME configuration defines the Java language, the virtual machine features and the minimum class libraries for a category\group of devices (“horizontal” market).

Profile

A J2ME profile is layered on top of configuration and address the specific demands of a specific “vertical” market (or device category). The profile typically includes class libraries that are far more specific than the class libraries provided in a configuration.

A device can support multiple configurations and therefore it can also support multiple profiles. Therefore, the vision of taking a specific application for mobile telephone and run it on the TV set top box (given that it supports the MID profile in addition to its “normal” more device specific profile) can become a reality.

A J2ME application is written for a specific profile. The profile is “based upon” a particular configuration and because of that all of the features of that configuration are automatically included in the profile. Manufacturers choose which profile(s) to support on each of their devices and once they choose the profile\s they must implement all the features of that\those profile\s.

Currently there are only two standard J2ME configurations:

Connected, Limited Device Configuration (CLDC) and the Connected Device Configuration (CDC). The classes that the CLDC and CDC configurations have might be inherited from the J2SE environment or a subset of these classes or new ones that don’t exist in J2SE. The following figure demonstrates the relationships between the CDC, CLDC and the J2SE.

The MID profile is only one profile. More profiles are on their way to be published. The following figure demonstrates the profiles and the configurations relationships.

This book focus in the CLDC configuration and MIDP(the MID profile). The MID profile was designed for mobile information devices such as cellular telephones, PDA’s and pagers.

The MID Profile

According to the specification, the MID profile has the following characteristics:

At least 128KB of non-volatile memory (non-volatile memory is memory that is capable of keeping its contents intact as the device is turned on and off. The ROM is one example for non-volatile memory) for the MIDP implementation.

At least 32KB of volatile memory for the heap.

At least 8KB of non-volatile memory for persistent data.

A screen of at least 96x54 pixels.

Pixel ratio approximately 1:1.

An Input mechanism – one of the following: keypad, keyboard or touch screen.

Two-way network connection.

The classes a MIDP application can use come from packages in both the CLDC and the MIDP. The packages the CLDC has are: java.lang, java.io, java.util, javax.microedition.io. The packages the MID profile adds are: javax.microedition.lcdui, javax.microedition.midlet and javax.microedition.rms.

Once a MID software is developed it can be categorized to one of the following three types of MID software:

1. Native Application which was compiled from C\C++ or other native language and runs directly on the device operating system. This kind of application is developed specifically for a specific device and it can run only on that device.

2. MIDP java application that was written in Java and that uses only the MIDP & CLDC APIs. This kind of application can run on any device that supports the MID profile.

3. Device-Specific application that was written in Java and uses in addition to the MIDP & CLDC APIs some specific API(s) that were\was developed specifically by the device vendor. These type of applications won’t run on other devices that don’t have those extra APIs.

The following pictures present several mobile telephones that support the J2ME (CLDC\MIDP). For more information about mobile telephones that support the J2ME technology visit http://www.javamobiles.com .

The KVM

The CLDC and the MID profile run on top of Sun’s K Virtual Machine (KVM), which is a compact, portable JVM specifically designed for small, resource-constrained devices. The “K” in KVM stands for “kilo”. It was so named because its memory is measured in tens of kilobytes. The currently minimum memory budget required by a KVM implementation is about 128 K (including the Virtual Machine, minimal libraries and some heap space).

In some devices the KVM is used on top of existing native software to give the device the ability to run Java content.

In other devices the KVM is used at lower level, implements the lower-level system and serves as the device main software that responsible for the device main activities.

Writing the first MIDlet

Writing a MIDlet is similar to writing an applet. The MIDlet we write is a class that extends the Midlet class (similar to declaring a class that extends Applet). To develop a MIDlet you will have to download the “Java 2 Micro Edition Wireless Toolkit” from www.javasoft.com. The code in this book were tested and run using the “Java 2 Micro Edition Wireless Toolkit 1.0.2 Early Access 2”. You can also find other alternative toolkits (The Motorola SDK, for instance). After all, the MIDP is only a specification that different vendors can adopt and develop their own implementation. The “Java 2 Micro Edition Wireless Toolkit” (J2MEWTK) contains a reference implementation of the MID profile as well as some other software tools that were designed especially for developing MIDP applications.

Coding:

Writing the source code of the MIDlet is the same like any other java code. Code the following simple example using your favorite text editor:

//filename:HelloIsrael.java

//reproduced or transmitted in any form or by any means without the

//written permission of the publisher.

import javax.microedition.midlet.*;

import javax.microedition.lcdui.*;

public class HelloIsrael extends MIDlet

{

private Display display;

private Form form;

public HelloIsrael()

{

form = new Form("Hello Israel");

display = Display.getDisplay(this);

}

public void startApp()

{

display.setCurrent(form);

}

public void pauseApp()

{

}

public void destroyApp(boolean cond)

{

}

Compiling:

When compiling the source code you should use the classes that belong to the MID profile implementation instead of the classes that belong to the J2SE (that you should have installed on your computer). To do so, you should point to the path in which the MIDP classes reside. You should write the following (in the command line):

javac –bootclasspath classesPath HelloIsrael.java

The –bootclasspath is one of the options that can be sent to the javac command when invoking it. This option is used to point out at the location of the bootstrap class files. Given that you use the J2MEWTK, and given that you have installed it with its default folder names in disk C, you should write the following:

javac -bootclasspath c:\j2mewtk\lib\midpapi.zip HelloIsrael.java

Alternatively, you can start the KToolbar utility application (part of the J2MEWTK). Under the “bin” folder you shall find the “KToolbar.bat” file that starts the KToolbar application. When it starts, choose the “New Project” option from its toolbar and create a new project (name it as you want). As a result of this step the “src” folder is created within a folder named after the project name you chose.The “HelloIsrael.java” file is saved in the “src” folder. Now, you can just choose the option “build” from the menu bar and let the KToolbar does the compilation job for you.

Preverifying:

Unlike the J2SE, when working with the CLDC configuration, the bytecode verification process is divided into two processes. The first takes place off the device (this is the preverifying step you should take) and the second process takes place on the device itself (the device just needs to do lightweight second verification before loading the classes). If the device gets a class that has not been preverified it is rejected.

The J2MEWTK contains a tool called “preverify” that performs the first step (the preverify.exe file resides in the “build\win32\tools” directory. It is recommended adding this directory to the path environment variable). The result of the preverify utility program is a new *.class file. Given that your current directory is the one in which the HelloIsrael.class was saved, all you have to type in the command line is:

preverify -classpath .;c:\j2mewtk\lib\midpapi.zip -d . HelloIsrael

In this case, the –d option tells preverify to write the preverified class file to the current directory. If you chose to use the KTookbar tool, then the preverifying step is done automatically for you, when you press the “build” button.

Running:

If you chose to use the KToolbar tool, then you can simple press the “run” button.

If you chose to work from the command-line, and given that the emulator.exe file resides in c:\j2mewtk\bin directory and the current directory is the one in which the HelloIsrael class resides, then you should do the following:

c:\J2mewtk\bin\emulator -classpath .;c:\j2mewtk\lib\midpapi.zip HelloIsrael

An alternative way for testing your MIDlet is by creating a .jad file that describes the MIDlet application and invoke it using the emulator utility application. The alternative way won’t be described at the moment.

The MIDlet life cycle is controlled by the JAM (Java Application Manager), a MIDlet management software that controls the process of installing, running and removing the MIDlets. When the user chooses to run a MIDlet, it is the JAM that creates an instance of the MIDlet class and runs methods on it. The sequence of method that will be invoked on the MIDlet subclass instance is defined by the MIDlet life cycle. Like the servlets and the applets, the midlets also have a well-defined set of states.

The JAM calls the different methods on the midlet to signify changes from one state to another. These methods include the following: startApp(), pauseApp(), destroyApp() and the MIDlet subclass constructors as well.

J2ME(CLDC\MIDP) comparing to the J2SE

The MID profile is built on top of the CLDC configuration. Some of the CLDC APIs is based on the basic APIs of the J2SE. The differences between the two (the CLDC and the J2SE) are as follows:

The J2ME(CLDC\MIDP) doesn’t support floating-point types.

The J2ME(CLDC\MIDP) doesn’t have the float and double primitive types and not the Flaot and Double classes.

The J2ME(CLDC\MIDP) java.lang package is a subset of the J2SE java.lang package.

The classes and interface that the J2ME(CLDC\MIDP) java.lang package has are:

Runnable, Boolean, Byte, Character, Class, Integer, Long, Math, Object, Runtime, Short, String, StringBuffer, System, Thread, Throwable, ArithmeticException, ArrayIndexOutOfBoundsException, ArrayStoreException, ClassCastException, ClassNotFoundException, Exception, IllegalAccessException, IllegalArgumentException, IllegalMonitorStateException, IllegalThreadStateException, IndexOutOfBoundsException, InstantiationException, InterruptedException, NegativeArraySizeException, NullPointerExcetion, NumberFormatException, RuntimeException, SecurityException, StringIndexOutOfBoundsException, Error, OutOfMemoryError and the VirtualMemoryError. Some of these classes don’t have the same API the J2SE classes have (they are subset to the J2SE classes).

The J2ME(CLDC\MIDP) doesn’t enable controlling the Class Loading process.

The J2ME(CLDC\MIDP) doesn’t allow you defining your own class loader. The JAM has a class loader that doesn’t allow accessing\controlling it.

The J2ME(CLDC\MIDP) doesn’t support Object finalization mechanism.

As you probably remember from the J2SE platform, using the Finalization mechanism has never been recommended. Therefore, not having the support of this mechanism can only be count as an improvement.

The J2ME(CLDC\MIDP) doesn’t support the reflection mechanism.

Not having the support of the reflection mechanism in the J2ME(CLDC\MIDP) profile has severe implications. Because of that we can’t use RMI and therefore we can’t use JINI :(. However, using one of the other J2ME profiles (such as the RMI profile) can be a solution.

The J2ME(CLDC\MIDP) doesn’t support a mechanism (like the JNI) that enables writing native methods.

If you decide to use the MID profile there is no way of combining the java code with other languages code.

The J2ME(CLDC\MIDP) multithreading mechanism is very similar to the one that the J2SE has.

As long as the multithreading isn’t complicated you will find the J2ME(CLDC\MIDP) multithreading support sufficient. Most of the deprecated methods from the J2SE edition, resume(), suspend() and stop() are not supported. The thread grouping mechanism and the daemon threads also are not supported.

The J2ME(CLDC\MIDP) has the Math class

The J2ME(CLDC\MIDP) Math class API is a subset of the J2SE version. Most of the methods, that the J2SE Math class has, don’t exist in the J2ME version.

The J2ME(CLDC\MIDP) has smaller version of the String and the StringBuffer classes

The J2ME(CLDC\MIDP) String and StringBuffer classes are very similar to the J2SE versions. Only few methods were omitted in the transition from J2SE to J2ME(CLDC\MIDP).

The J2ME(CLDC\MIDP) has smaller version of the System and the Runtime classes

Lots of methods that exist in the J2SE don’t exist in the J2ME(CLDC\MIDP). One example is the exec() method that belongs to the Runtime class (in its J2SE version) and doesn’t exist in the J2ME(CLDC\MIDP) version since the MIDP application can’t run out of the JVM’s bounds.

The J2ME(CLDC\MIDP) java.util package include only few of the classes and interface that exist in the J2SE version.

The classes and the interfaces that the J2ME(CLDC\MIDP) supports in its version of the java.util package are: Enumeration, Calendar, EmptyStackException, NoSuchElementException, Date, Hashtable, Vector, TimeZone, TimerTask, Timer, Stack and Random. One of the biggest changes is the missing of most of the collection classes.

The new Timer and TimerTask classes that were introduced in the J2SE 1.3 version were included in the J2ME (CLDC\MIDP).

The J2ME(CLDC\MIDP) java.io package include only few of the classes and interfaces that exist in the J2SE version

The classes and the interface that the J2ME (CLDC\MIDP) supports in its version for the java.io package are: InputStream, OutputStream, ByteArrayInputStream, ByteArrayOutputStream, DataInputStream, DataOutputStream, Reader, Writer, InputStreamReader, OutputStreamWriter, PrintStream, EOFException, InterruptedIOException, IOException, UnsupportedEncodingException, UTFDataFormatException and the DataOutput and DataInput interfaces.

The biggest changes are the serialization mechanism that the J2ME(CLDC\MIDP) doesn’t support and the files streams (The local file system doesn’t exist in MIDP devices).

The encoding mechanism still exists. However, in the J2ME(CLDC\MIDP) there are fewer available encoding than in J2SE. You can get the default encoding by calling the System.getProperty(“microedition.encoding”) method.

The J2ME (CLDC\MIDP) still supports the resource files idea (as long as these files are packaged within the MIDlet suit’s JAR file). To get an input stream connected to specific resource file you can use the getResourceAsStream() method that was declared in the Class class.