IN THIS CHAPTER
Let's warp back to 1995, the year when Java first came out. Mobile phones were rare, brick-like gizmos, and the Internet was just emerging outside the realm of university and government geeks.
A lot has happened since then. The Web business grew, expanded beyond all reason, exploded, then established itself as a stable mass medium. And mobile phones swept the world, especially throughout Europe and Asia, where phones are owned by two-thirds of the population. It is now expected that the total number of wireless subscribers will exceed one billion by the end of 2002, and the majority of these new appliances will be connected to the Internet.
So how does Java fit into in all this?
In the beginning, there was only one edition of Java. Despite setbacks—such as the rumor that the Indonesian island of Java sued Sun Microsystems—Java took off. Java was lucky enough to have caught the Web wave, and soon become a favored language among Internet developers.
Java grew to be a big sucker—far too massive to fit on small devices. There was clearly a need for a new breed of Java, one that fit and made the most of limited devices. In 1999, Sun Microsystems finally decided to split Java efforts into three directions. Each of these platforms would be targeted at different types of devices, as shown in Figure 8.1.
Java 2 Platform, Standard Edition (J2SE)—For personal computers and workstations, and used mostly in the office or home. (http://java.sun.com/j2se/)
Java 2 Platform, Enterprise Edition (J2EE)—For servers and middleware stations, and usually used in secured corporate areas. (http://java.sun.com/j2ee/)
Java 2 Micro Edition (J2ME)—For small devices like mobile phones, pagers, PDAs, and communicators; as well as home devices such as microwaves and refrigerators, which are less powerful than personal computers. (http://java.sun.com/j2me/
)
When developers talk about programming with Java, they are usually referring to J2SE, which is the basic Java standard. Java applets and Java applications run using J2SE, and it forms the core of J2EE and J2SE.
J2SE contains a fast virtual machine with a just-in-time (JIT) compiler, developer tools, and a set of libraries vital for the development of applications.
Unlike J2SE, J2EE represents a middleware container (an add-on to J2SE) that supports JSPs, Java Servlets, Enterprise JavaBeans (EJBs) and other J2EE APIs. It is meant for enterprise, multi-tier applications, where companies invest in expensive servers. With J2EE, developers prefer to focus on business logic instead of server implementation in order to speed up the development cycle and to make applications more robust.
But the platform we're focusing on in this book is J2ME. As micro appliances become increasingly important in our business lives, they also become potential platforms for heavy entertainment, games, and other types of fun. J2ME makes game development on such devices a reality.
And best of all, once you write a game that works on one type of J2ME device, it can easily be modified to work on them all.
In the past, micro devices came with their features hardcoded. Modern devices, however, support customization through the downloading of new services and applications from the Internet. Most major manufacturers have chosen J2ME as the standard for developing and deploying these new services.
There have been several attempts to bring Java technology down to the small devices. These efforts include Jump (http://hewgill.com/pilot/jump/) and Waba (http://www.wabasoft.com).
Jump is a Java language front-end—that is, it allows you to write programs in Java, but doesn't compile programs into Java classes. Rather, Java code is interpreted into assembly code and compiled natively. This is nice and fast, but it isn't really Java, and lacks Java's portability.
Waba, on the other hand, has its own virtual machine. However, it takes a few liberties with its capabilities and doesn't meet Sun's exact Java standard.
The Java 2 Micro Edition (J2ME) was created by Sun, and fits in perfectly with other Java technologies. The language is focused specifically on the consumer and embedded market.
The main benefits of pure J2ME are as follows:
Cross-platform compatibility—An application that uses 100% pure J2ME APIs can easily run on the wide range of devices of different models and from different vendors. This is perhaps the most compelling argument for using Java. Theoretically, an application written for a Motorola cell phone can also run on a Nokia, or even a Palm. The same code could be compiled and run as an applet in a Web browser, as an application on a million-dollar server machine, in your car's dashboard, or—eventually—in a Java-powered neural link to your own brain!
Dynamic content—Applications on devices never go out of date. Just download a new one to meet new needs.
Strong security—Security has always been one of Java's biggest concerns. Applications written in J2ME cannot access the device's hardware or other resources, making it nearly impossible to create viruses, Trojan horses, or other malicious programs.
Large developer community—There are a few million Java developers already available worldwide on developer's portals, mailing lists, and discussion boards.
Although different consumer devices such as mobile phones, pagers, and set-top boxes have many things in common, they also differ in form, function, and features. To address this diversity, J2ME attempts to be modular and easily customizable.
In order to support the kind of flexibility demanded by the embedded marketplace, the J2ME architecture is designed to be modular and scalable. This modularity and scalability is defined by the technology as three layers of software built upon the operating system of the device, as shown in Figure 8.2.
The JVM layer is an implementation of a Java virtual machine customized for a particular device's operating system and supports a particular J2ME configuration.
The configuration layer defines the minimum set of Java virtual machine features and Java class libraries available on a particular category of appliances. This is usually a subset of J2SE.
The profile layer defines the minimum set of APIs available on a particular family of devices, such as mobile phones or PDAs. Applications are written for a particular profile, and are thus portable to any device that supports that profile. A device can support multiple profiles.
A J2ME configuration defines a minimum platform for each category of devices, each with similar requirements for total memory availability and processing power. A configuration defines various items that a hardware manufacturer or developer can expect to be available:
Java programming language features
Java virtual machine features
Basic Java class libraries and APIs
At a high level, J2ME currently targets two categories of devices, each with its own configuration. These configurations were hammered out by companies such as Sun, 3COM, Bull, Ericsson, Matsushita, Mitsubishi, Motorola, Nokia, NTT DoCoMo, and Siemens:
Connected Device Configuration (CDC)—This configuration is for shared and fixed connected information devices. Typical representatives of this category are TV set-top boxes, Internet TVs, and Internet-enabled screenphones. These devices have a large range of user interface capabilities, and memory availability between 2 and 16 megabytes. They usually use high-bandwidth network connections, mostly using TCP/IP. More info can be found at http://java.sun.com/products/cdc/.
Connected, Limited Device Configuration (CLDC)—This configuration is for mobile-connected information devices. Mobile phones, pagers, and PDAs are examples of devices in this category. They have a very simple user interface with limited displays, a minimum memory size starting from 64 kilobytes, and low bandwidth network connection—often with unstable connectivity. Network communications are often not based on the TCP/IP protocol suite. Visit http://java.sun.com/products/cldc/ for additional information.
A J2ME profile is a layer on top of the configuration. It addresses the specific demands of a certain device family. Its goal is to keep interoperability within a certain device family by defining a standard Java platform for that market.
Profiles can serve two distinct portability requirements:
A profile provides complete APIs for implementing applications for a specific kind of device, such as a microwave, TV, or pager.
A profile can also be created to support a significant group of applications that might be run on several categories of devices—for example, home banking or gaming applications.
It is possible for a single device to support several profiles. Some of them will be device-specific, and others will be application-specific.
Figure 8.3 shows a high-level view of how a profile such as the MIDP fits into a device. The lowest-level block represents the Mobile Information Device hardware itself. On top of this hardware is the native system software. This layer includes the operating system and libraries used by the device.
The next level is the CLDC or another configuration, which represents the K virtual machine and the associated libraries defined by the CLDC specification. This block provides the underlying Java with functionality upon which higher-level Java APIs are built.
There are two categories shown on top of the CLDC: MIDP APIs and OEM-specific APIs.
For example, Siemens has a special game API profile, which is discussed in Chapter 23, “Siemens Game API.” Applications that use OEM-specific APIs might not be portable to the other MIDP devices.
Finally, the third-party applications—any games or other programs you write—sit atop all these APIs.
The Kilobyte virtual machine (KVM) is a particular implementation of a Java virtual machine meeting the CLDC specification. As such, the KVM is a small and portable Java virtual machine, designed for small devices with limited resources. The main goal was to create the smallest possible virtual machine that would still maintain all the central aspects of the Java language, but would run on resource-limited devices with only a few hundred kilobytes of total memory.
It was designed to be
Small, with a static memory footprint between 40 and 80 kilobytes
Clean and portable
Modular and customizable
Complete and fast
The KVM is implemented in the C programming language; therefore, it can be easily ported to various platforms for which a C compiler is available. The virtual machine has been built around a bytecode interpreter with various flags and options to speed up the porting and improve the space optimization. It was already successfully ported to more than 25 devices, and it can be built with any ANSI-compliant C compiler.
The Java Application Manager (JAM) is a part of the KVM that serves as an interface between the operating system and the virtual machine. Like the KVM, the JAM is built-in to any J2ME-supporting device. The JAM works in the background, helping to launch your programs.
The JAM assumes that applications are available for downloading as JAR files by using networking or storage protocol. It reads the contents of the JAR file and its descriptor file from the Internet, and launches the KVM using the main class as a parameter. The JAM also handles each application's life cycle, installing, launching, and deleting Java apps.
The entire CLDC implementation generally fits in fewer than 128 kilobytes. Its specification assumes that applications can be run in as little as 32 kilobytes of Java heap memory. Of course, this size is only theoretical. Most devices include not only the base CLDC classes, but tons of profile classes (such as MIDP) to handle user interface, networking, and other essential details.
The CLDC configuration addresses the following areas, using the following Java packages:
java.lang.*—. This represents the essential Java classes for working with the system and with different data types.java.util.*—. This is the standard set of utility classes for working with collections and dates.javax.microedition.io.*—. A non-standard Java package that provides additional network functionality.
The Java virtual machine supporting CLDC is compatible with the original Java language specification by James Gosling, except for the following differences:
No support for floating-point data types (no float and double)
No support for finalization of class instances ( the method
Object.finalize()does not exist)Limitation on error handling
No support for Java Native Interface (JNI)
No reflection features
No support for thread groups or daemon threads
No weak references
Floating-point support has been omitted primarily because of the majority of the CLDC target devices not having hardware support for floating point arithmetic. Other features were eliminated mostly because of strict memory limitations or potential security concerns in the absence of the full J2SE security model.
The CLDC requires the capability of a Java virtual machine to identify and reject an invalid classfile. Because the standard classfile verification approach defined by J2SE is too memory-hungry for small appliances, the CLDC defines an alternative mechanism for verification.
In this alternative, each method in a downloaded Java classfile contains a stack map attribute. This attribute is newly defined in the CLDC. It is added to the standard classfile by a pre-verification tool that analyzes each method in the classfile. This step is typically performed on a server or desktop system before the classfile is downloaded to the device.
The presence of this attribute enables a CLDC-compliant Java virtual machine to verify Java classfiles much more quickly and with less VM code and RAM consumption, but with the same level of security as in J2SE.
We will go into more detail about how to pre-verify in Chapter 9, “Creating A MIDlet.”
The first and, at the present, only available standard profiles on the market is the Mobile Information Device Profile (MIDP). This section covers some of the basics on MIDP, but for more detailed information, go to http://java.sun.com/products/midp/.
The MIDP is designed to run on top of the CLDC. Devices that support the MIDP should have the following minimum set of characteristics:
Display:
Screen size of 96×54
Display depth of 1 bit
Aspect ratio of pixels approximately 1:1
Input:
Memory:
128 kilobytes of non-volatile memory for the MIDP components
8 kilobytes of non-volatile memory for application-created persistence data
32 kilobytes of volatile memory for Java runtime (for example, heap memory)
Networking:
Two-way, wireless, possibly intermittent, with limited bandwith
Most devices that implement the MIDP specification will be, at least initially, devices that exist on the market today, such as mobile phones and pagers.
MIDP was first released in September 2000. Before that, two Asian mobile operators announced their own non-standard profiles:
Kittyhawk—Created by LG Telecom and Sun Microsystems. This has been replaced by MIDP.
iAppli—Created by NTT DoCoMo. This is discussed fully in Chapter 22, “iAppli: Micro Java with a Twist.”
The next MIDP specification, which also runs on Palm OS devices, will be announced in April 2002, and is being produced by the Mobile Information Device Profile Expert Group (MIDPEG), whose members include America Online, Ericsson, Motorola, Nokia, Palm, Sun Microsystems and others.
J2ME is a platform that is slowly being accepted and deployed by most hardware manufacturers. In the near future, the majority of mobile phones, TV set-top boxes, pagers, and other micro devices will support J2ME.
Currently, CLDC is the only J2ME configuration available on the market, with two profiles laid on the top of it: MIDP and iAppli. Because the latter profile is used only by NTT DoCoMo, MIDP is the gold standard for small devices.
The next chapter will show you how to begin developing a MIDP application.