Understanding Java ME

The Java Micro Edition ( Java ME) is the version of the Java platform that’s designed for use with small devices such as cell phones, personal digital assistants (PDAs), TV set-top boxes (for web browsing and e-mail without a whole computer), and embedded devices. Since these devices vary quite a bit in their capabilities, the Java ME platform has two different configurations, each with its own choice of profiles. The Connected Limited Device Configuration (CLDC) is the configuration you’ll be working with in this book. It’s designed for cell phones and lowlevel PDAs. More precisely, CLDC is intended for devices with a 16-bit or 32-bit processor, with at least 160KB of nonvolatile memory, at least 32KB of volatile memory, and some network connectivity, possibly wireless and intermittent. CLDC’s unique profile is the Mobile Information Device Profile (MIDP). This book covers MIDP versions 1, 2, and 3, although the focus will be on MIDP 2 since that is the current industry standard for cell phones and will continue to be the standard for some time. The other configuration possibility associated with Java ME is the Connected Device Configuration (CDC), which isn’t specifically covered in this book. Starting with MIDP 3, some CDC devices will be able to run MIDP applications; however, from the MIDP application’s perspective, the configuration must behave as if it were CLDC, and therefore, no CDC-specific programming is covered here.
The configuration specifies the type of Java Virtual Machine (JVM) that’s used and what will be included in the minimal class libraries (the java.* packages and the javax.microedition.io package in the case of CLDC). CDC specifies a complete JVM, but the JVM of CLDC has some limitations compared to the standard JVM. A profile is added on top of the configuration to define a standard set of libraries (the other javax.microedition.* packages in this case). MIDP contains packages for application lifecycle, a user interface, media control, input/output, data storage, and security.
In addition to its configuration and profile, a Java ME–capable device may also have a set of optional application programming interfaces (APIs) available. Some are proprietary, but many are standard. Standard optional APIs are defined in Java Specification Requests (JSRs), which are
submitted, reviewed, and published through the Java Community Process (JCP). You can download the precise specifications for any JSR (free) from the JCP web site (http://jcp.org/). CLDC, CDC, and MIDP are all defined as JSRs through the Java Community Process.

How the CLDC Differs from the Rest of the Java Universe

If you’re coming to Java ME from a background of programming for Java Standard Edition (Java SE) or Java Enterprise Edition (Java EE), things should look pretty familiar, but just a little bit different. It’s like Java in a parallel universe where everything has been streamlined to be as small and efficient as possible. You have fewer tools at your disposal in terms of built-in libraries, and you need to place greater priority on writing tight, efficient code than a Java SE or Java EE developer would. Those are already good reasons to switch to Java ME if you’re one of those people who loves a good challenge. Another motivation for making the switch to Micro Edition is that the applications are so small that you typically get to design most or all of the program yourself instead of being a cog writing a part of an obscure module.
The designers of the CLDC specification have made an effort to make CLDC resemble the standard platform as closely as possible, and they’ve done a pretty good job of it. Nothing critical to small applications appears to be missing. I’ll give a general outline of the changes here, and I’ll refer you to later chapters in this book for a more in-depth discussion of the aspects that have changed the most dramatically.

Differences in the JVM
The JVM specified in CLDC is mostly the same as the standard JVM. Unsurprisingly, a few of the costlier noncritical features have been eliminated. One example is the method Object.finalize(). According to the JavaDoc, the Object.finalize() method is called on an object when the JVM determines that it’s time to garbage-collect that object. The actions the object can take in its finalize() method aren’t restricted, so in particular it can make itself available again to currently
active threads! The garbage collection algorithm is already expensive, and this method clearly undermines its efficiency by obligating the JVM to recheck objects that had already been marked as garbage. It’s no wonder this method was eliminated in CLDC, since it’s not hard at all to keep track of the objects that you’re still using without requiring the JVM to check with you before throwing anything away.
Some of the other areas where the JVM’s set of features have been reduced are in security, threads, and exceptions/errors. See the “Understanding Protection Domains and Permissions” section in Chapter 8 for a discussion of the differences in the security model. See the “Differences
Between CLDC Threads and Threads in Standard Java” section in Chapter 4 for information about threads. The changes in the error-handling system are that CLDC doesn’t allow asynchronous exceptions and that the set of error classes has been greatly reduced. Instead of 22 possible errors, you now have only OutOfMemoryError, VirtualMachineError, and Error. On the other hand, almost all the exceptions in the java.lang.* package have been retained.

You may not notice a few changes to the JVM just by looking at the API. In CLDC, the JVM is allowed to perform some optimizations (such as prelinking classes) that were disallowed to the standard JVM. Such changes shouldn’t concern the application programmer in general. The one exception is that an additional preverification stage has been added after compilation. The preverification process adds extra information to the class file to make the bytecode verification
algorithm easier at runtime when the device checks that your class file is valid before using it. You easily accomplish the preverification step with standard tools (see the “Using KToolbar” section and the “Building with Ant” sidebar later in this chapter). Preverification isn’t technically required 100 percent of the time, but it aids in compatibility, and there’s no reason not to do it.
One more general item to be aware of is that although a CLDC-compliant platform is required to support Unicode characters, it’s required to support only the International Organization for Standardization (ISO) Latin 1 range of characters from the Unicode standard, version 3.0. For more information about character encoding in Java, see http://java.sun.com/ javase/6/docs/technotes/guides/intl/encoding.doc.html. Also, the initial version of CLDC (1.0) did not include floating-point numbers as simple data types (double and float). These were added in the newer version, CLDC 1.1.

Select good PHOTO OPPORTUNITIES

Unless you have specific reasons to shoot particular scenes or subjects, the best photo opportunities for you are those things that you enjoy. If you enjoy gardening and appreciate the thousands of different variations of iris, shoot irises. Or if you are a birdwatcher and find pleasure in watching wildlife, choose places where you can find birds and other wildlife in settings that make great photographs. When planning a trip, give yourself plenty of time to stay and take photographs. Allow yourself some time for bad weather or other shooting conditions that prevent you from photographing. You can spend an entire day or more at a site and not have good enough light to shoot. Do not fall into the trap of trying to see too much too quickly. You may miss the kinds of shots that you had hoped to capture because you saw everything and shot little. Photography takes time, and time is often the most important factor in getting truly great photographs.
-- When shooting well-known places such as the Grand Canal in Venice or Canyon de Chelly in Arizona, take classic photos and then shoot creatively, too.


-- It took several hours of waiting to get a shadow on this otherwise overly bright photograph of the White House ruins in Canyon de


-- Chelly in Arizona. If you are willing to hike, you may be rewarded with photos that are well worth the effort that it took to get there.


-- This small backyard pond offers many subjects to photograph. Being close to home, it is easy to pick the best light to shoot in.

-- This frog was sunning on a rock on the edge of the pond shown in the preceding photo.

Photo Tip!
When you find a good place to take photographs, visit it again and again. Your photographs will improve each time that you return to the location because you will learn when to visit and what to shoot.

Did You Know?
Some of the best photo opportunities may be in your own backyard. Learn to see differently and look for details, shapes, or colors that make good photographs and then capture them.


Photo Tip!
Use the Internet to learn where and when to shoot. There are many online guides and forums that provide all the information you need to find wonderful places and subjects to shoot that will suit your interests.