Shrinking Java to Fit by Williamhuang87


									CHAPTER               2

Shrinking Java to Fit

M    aking Java run on constrained devices remains a challenge, even nearly a decade
after the first attempts to do so. However, the configurations provided by Java ME are
helping to meet this challenge by bringing the Java platform to the widest possible selec-
tion of devices. By splitting Java into separate configurations—the CLDC for devices with
the lowest possible throughput, and the CDC for constrained mobile devices with mod-
erate memory and processing power—Java ME can provide a computing environment
for nearly every mobile device.
     In this chapter, I show you the explicit differences between Java ME and Java SE.
I begin with the CLDC, showing you just what’s different between past and present
versions of the CLDC’s virtual machine and the virtual machine running the Java SE.
Next I look at the CDC the same way. Finally, I turn your attention to the class libraries
accompanying each of these configurations, showing you precisely which classes both
the CLDC and the CDC support.

Making It Fit: The CLDC
To understand the limitations of the Java ME CLDC, it’s important to understand a bit
about the history of the CLDC itself. The CLDC stems from early in the history of Java
when mobile devices were veritable cripples by today’s standards. Mobile phones had
well under a megabyte of heap and were powered by processors that would be consid-
ered anemic by today’s standards. The initial release of the CLDC was based on an
entirely new virtual machine for small devices, the Java KVM. Consequently, it lacked a
lot of what Java developers were used to. CLDC 1.0, which was documented in JSR 30 in
2000, was the starting point for what has become the Java ME platform.
     To keep pace with developments in hardware capabilities and manufacturing costs,
an expert working group of more than 20 companies revised the CLDC standard, result-
ing in JSR 139, which is the standard that defines CLDC 1.1. This standard, completed in
2002, took into account the growing capabilities and markets for mobile devices, and it
added back some features stripped from Java to make Java fit on mobile devices during
the brief period that CLDC 1.0 was available.


          The distinction between the CLDC 1.0 and 1.1 releases may or may not affect your
     development approach, as the overwhelming majority of new devices sold today support
     CLDC 1.1 (or the CDC, in fact, for some higher-end devices). For example, as I write this,
     virtually all wireless operators’ Java-enabled feature phones—those phones subsidized by
     operators to provide a mix of features at a low cost to drive both voice and data uses—are
     CLDC 1.1–compliant. Even accounting for device churn (the rate at which users buy new
     devices), there are countless CLDC 1.0 devices on the market, and a savvy developer may
     well be able to wring revenue from these users. On the other hand, many of the com-
     pelling features of the Java ME platform (available through packages documented by the
     JSR process, as I discuss in Chapter 1), such as multimedia and 3D graphics, are only
     available on relatively new handsets, which typically run CLDC 1.1 and MIDP 2.0 or 2.1.
     As a result, when you plan your application, you should balance the need for APIs pro-
     vided by a later version of the CLDC or MIDP with the business case provided. You’ll need
     to answer this question: do the technology requirements for your application so drasti-
     cally reduce the number of devices on which you can deliver your application that your
     business case becomes invalid? This is a common theme for cutting-edge Java ME devel-
     opers, but less so now than in years past, and over time (as I discuss in the section
     “Looking Toward the Future of the CLDC” in this chapter) it should diminish entirely.

     Understanding the Present: CLDC 1.1
     Cost and power consumption significantly limit the capabilities of even today’s mobile
     devices. While consumer demand for high-capability personalizable devices remains
     high, manufacturing cost remains a key factor and drives the selection of low-cost com-
     ponents (meaning less memory, slower processors, and so forth). While Moore’s law has
     driven ever-faster and ever-cheaper devices in the hands of consumers, power sources
     have been unable to keep up, making power management another key challenge for
     mobile devices. Consequently, there continues to be constrained devices and a role for
     the CLDC on those devices.
         Specifically, CLDC 1.1 differs from Java SE in the following ways:

         • CLDC 1.1 offers no finalization of object instances: CLDC libraries, by definition,
           do not include the method Object.finalize.

         • CLDC 1.1 doesn’t support asynchronous exceptions: The virtual machine does not
           throw asynchronous exceptions, and you cannot invoke Thread.stop, as it doesn’t
           exist in the CLDC.

         • CLDC 1.1 supports only a limited number of the java.lang.Error subclasses:
           For other errors, the CLDC either halts the virtual machine in an implementation-
           specific manner or throws the nearest defined java.lang.Error subclass. (See the
           “Changes to java.lang.Exception” section later in this chapter.)
                                                                     CHAPTER 2 ■ SHRINKING JAVA TO FIT         21

    • CLDC 1.1 doesn’t support thread groups or daemon threads: The CLDC does sup-
      port multithreading, but if you need to manage a group of threads, you must use
      individual thread operations on members of a collection.

    • Class file verification is a two-step process in CLDC 1.1: As I discuss in the “Building
      CLDC/MIDP Applications” section in Chapter 3, the CLDC requires a preverifica-
      tion step during application development and a subsequent completion of
      verification after downloading.

    • For security reasons, CLDC 1.1 doesn’t support user-defined class loaders: The CLDC
      must have an internal class loader that other code cannot override, replace, or
      reconfigure in any way.

     With the possible exception of CLDC 1.1 lacking class finalization and thread groups,
these differences are unlikely to affect your approach to application development. Larger
in scope, however, is the reduction of the CLDC class library itself, which I explore later in
the chapter (in the section “Changing the Java Class Library to Fit the CLDC”).

                               MOORE’S LAW AND MOBILE DEVICES

  Moore’s law—the observation that the number of transistors that can be fit on the die of an integrated
  circuit is increasing exponentially—has driven many facets of the computing revolution, including the
  increases in computing speed and memory density for more than 50 years. Documented by Gordon
  Moore in an article in Electronics Magazine in 1965, the law isn’t one of nature, but rather a recognition
  of the economies of scale provided by integrated circuit production.
        For mobile devices, Moore’s law brings two key points: the ever-dropping cost of each transistor
  means that more computing power can be purchased for less money, and that the increased transistor
  density brings faster devices with more memory in portable form factors at the same exponential pace
  as it brings to desktop users. That is not to say, however, that the capabilities of mobile and desktop
  devices will converge, as Moore’s law is in play for larger computing platforms as well.
        Moreover, one area remaining largely untouched by Moore’s law is in providing energy for mobile
  devices. While the battery industry has seen many improvements in technology over the last two
  decades, these advancements have not been exponential in nature, leading to aggressive work on the
  part of hardware and software developers to manage power consumption at the hardware and soft-
  ware levels. This has a direct impact on computational resources, of course, which consume power
  while operating.
        These factors are likely to persist into the future, meaning that while mobile devices continue to
  get increasingly powerful, it’s unlikely that mobile devices and desktops will ever truly converge.
  Instead, it’s likely that mobile devices will become sufficient to support the majority of operations per-
  formed by yesterday’s desktops—something I talk more about in the “Looking Toward the Future of the
  CLDC” section later in this chapter.

     Looking Back at CLDC 1.0
     CLDC 1.0 had significantly more limitations than CLDC 1.1, as you can imagine when
     you consider the time in which it was developed. When developing a CLDC 1.0–
     compliant application, you must consider the following limitations:

         • No floating-point operations: CLDC 1.0–compliant virtual machines have no
           support for floating-point byte codes, nor do they have library APIs that perform
           floating-point math. These limitations mirror the capabilities of the processors
           typically targeted by CLDC 1.0.

         • No support for weak references: The WeakReference declaration is not supported by
           CLDC 1.0–compliant virtual machines.

         • No support for named threads: The CLDC-compliant virtual machines have no
           support for naming threads.

         • Different uses of java.util.Calendar, java.util.Date, and java.util.TimeZone classes:
           These classes differ significantly from their Java SE counterparts.

     Looking Toward the Future of the CLDC
     Although I believe that true convergence of capability between mobile devices and
     fixed devices remains a long way off (see the “Moore’s Law and Mobile Devices” side-
     bar), mobile devices are arguably reaching parity with desktop devices in terms of basic
     usability for many applications, including data processing, multimedia, entertainment,
     social networking, and user-generated content. Already, some high-end wireless termi-
     nals, such as those sold by Nokia and Sony Ericsson, offer CDC-compliant runtimes
     as well as CLDC-compliant runtimes. Looking into the future, representatives of Sun
     have already stated that eventually the Java ME and Java SE interfaces will merge into
     a single platform.
          Does this make the CLDC less relevant? Certainly not, as literally billions of
     devices running the CLDC are already in consumers’ hands, and billions more are to
     be shipped in the coming years. Instead, expect to see a filling in of the gaps between
     the CLDC and the full Java SE platform, much as the transition from CLDC 1.0 to
     CLDC 1.1 filled in gaps.
                                                           CHAPTER 2 ■ SHRINKING JAVA TO FIT      23

Making It Fit: The CDC
In some ways, the CDC has had a more tumultuous history than its smaller cousin, the CLDC.
Beginning life as PersonalJava and based on Java 1.1.8, the CDC is actually quite old, dating
back to the late nineties. PersonalJava consisted of a heavily optimized Java VM and an associ-
ated class library that incorporated most of the Java stack, including a GUI, for application
developers on set-top boxes, high-end connected wireless terminals, and other products.
     A few years ago, Sun announced the trio of flavors for Java: Java 2 Platform, Micro
Edition (J2ME), Java 2 Platform, Standard Edition (J2SE), and Java 2 Platform, Enterprise
Edition (J2EE). While PersonalJava remained, it was subsumed into Java ME and later
reached its end of life, meaning that Sun withdrew support for the platform.
     At the same time, Sun introduced JSR 36, defining the CDC. The CDC targets devices
requiring an entire virtual machine for hardware that, through optional extensions, may
run the entire Java 2 platform. JSR 36 bases its implementation on Java SE 1.3, and it
includes all additional interfaces defined by the CLDC, providing a migration path for-
ward from CLDC devices. JSR 218, defining CLDC 1.1.2, normalized the interfaces
provided against Java SE 1.4.2, helping ensure parity going forward between the CDC
and larger Java environments.
     It does little good to identify each and every class in the CDC, because the list is the
same as the list of classes for Java SE. It is, however, worth your while for me to call out
the packages included in the CDC, because while the CDC provides a baseline for com-
patibility, it does not provide the user-interface classes necessary to build a full
application. Table 2-1 shows the packages provided by the CDC.

Table 2-1. Packages Provided by CDC 1.1.2

         The CDC is a more restrictive environment than Java SE. Be aware of the following:

         • If the CDC implementation with which you’re working supports invoking native
           methods, you must use Java Native Interface (JNI) 1.1 to interface with those native

         • If the CDC implementation with which you’re working supports a debugging
           interface, you must use the Java Virtual Machine Debug Interface (JVMDI) for

         • The CDC doesn’t support secure code signing, certificates, the key store, and the
           JDK 1.1 and interfaces.

        Typically, any CDC implementation you encounter is accompanied by one or
     more profiles, such as the Foundation Profile, giving you support for GUIs and other

     Changing the Java Class Library to Fit the CLDC
     Shrinking the Java virtual machine was only part of the trick to making the CLDC fit
     on mobile devices. One of Java’s key benefits to developers is its robust class library.
     However, all of that code is also in Java and consumes precious read-only memory
     space on constrained devices, and some classes may not even be appropriate because
     of their runtime memory consumption. Of course, without its class hierarchy, Java
     wouldn’t be nearly as compelling a platform, so the architects of the CLDC struck a
     balance, establishing an environment with relatively few Java interfaces that can run
     on the widest possible variety of devices while supporting a great number of applica-
     tions. (And of course, device manufacturers are free to add—and have added—a great
     number of additional interfaces.)
          Besides the obvious—as you know, neither the AWT nor Java Swing are part of the
     CLDC—many other classes, and some methods of other classes, are omitted from the
     CLDC. In the following sections, I show you which parts of the java.lang, java.util, and hierarchies are different between CLDC 1.0, CLDC 1.1, and Java SE, as well as the
     additions made by the CLDC to the Java family of libraries.

     Changes to the java.lang Package
     Table 2-2 lists the classes inherited from the java.lang package. Many of these classes are
     a subset of the implementation found in Java SE.
                                                             CHAPTER 2 ■ SHRINKING JAVA TO FIT   25

Table 2-2. java.lang Classes Supported by CLDC Version

CLDC 1.0                              CLDC 1.1
ArithmeticException                   ArithmeticException
ArrayIndexOutOfBoundsException        ArrayIndexOutOfBoundsException
ArrayStoreException                   ArrayStoreException
Boolean                               Boolean
Byte                                  Byte
Character                             Character
Class                                 Class
ClassCastException                    ClassCastException
ClassNotFoundException                ClassNotFoundException
Error                                 Error
Exception                             Exception
IllegalAccessException                IllegalAccessException
IllegalArgumentException              IllegalArgumentException
IllegalMonitorStateException          IllegalMonitorStateException
IllegalThreadStateException           IllegalThreadStateException
IndexOutOfBoundsException             IndexOutOfBoundsException
InstantiationException                InstantiationException
InterruptedException                  InterruptedException
Integer                               Integer
Long                                  Long
Math                                  Math
NegativeArraySizeException            NegativeArraySizeException
NumberFormatException                 NumberFormatException
NullPointerException                  NullPointerException
Object                                Object
OutOfMemoryError                      OutOfMemoryError
Runnable                              Runnable (interface)
Runtime                               Runtime
RuntimeException                      RuntimeException
SecurityException                     SecurityException
Short                                 Short


     Table 2-2. Continued

     CLDC 1.0                               CLDC 1.1
     String                                 String
     StringBuffer                           StringBuffer
     StringIndexOutOfBoundsException        StringIndexOutOfBoundsException
     System                                 System
     Thread                                 Thread
     Throwable                              Throwable
     VirtualMachineError                    VirtualMachineError

     Changes to java.lang.Exception
     As I stated previously, the exception hierarchy for the java.lang package is significantly
     smaller than the hierarchy for Java SE.

     Changes to java.lang.Object
     The key change to the Object class—and therefore the entire Java hierarchy—is the
     absence of the finalize method. As you know, the memory manager invokes a method’s
     finalize method just before garbage collection; in the CLDC, there’s no way to hook the
     garbage-collection process in this manner. This is as it should be: memory is often a pre-
     cious commodity on Java ME devices anyway, so you should explicitly clean up resources
     when you’re finished using them.
          The Reflection API is also not part of the CLDC; the memory footprint it demands
     just isn’t feasible. Of course, without reflection, there’s no RMI, and without RMI, there’s
     no Jini—Sun’s platform for Java-based distributed computing.

     Changes to java.lang.Math
     As you might imagine, with the removal of floating-point support in CLDC 1.0, the
     java.math class was stripped of floating-point operations, leaving only operations with
     all-integer signatures such as min and max. With the reintroduction of floating-point
                                                         CHAPTER 2 ■ SHRINKING JAVA TO FIT   27

support in CLDC 1.1, the library was again brought to parity with Java SE, and these
methods returned to the library.

Changes to Multithreading
The core essence of multithreading remains unchanged between the CDLC and the
implementations of Java for larger-footprint devices. However, some key differences exist:

    • CLDC 1.0 doesn’t support thread naming and the interrupt method; however, you
      can find them in CLDC 1.1.

    • The suspend, resume, and stop methods, now deprecated in Java SE, are wholly
      absent from the CLDC.

    • The CLDC doesn’t support thread groups and daemon threads.

Changes to java.lang.Runtime
The runtime facility is vastly changed between Java SE and Java ME for both security and
memory reasons. It provides five methods:

    • getRuntime: This static method returns the global runtime.

    • exit: Although you can invoke this method, it won’t exit the runtime; the entire
      application life cycle is managed by the application manager and MIDlets
      (see Chapter 3 for more details).

    • totalMemory: You can use this method to determine the amount of total memory
      that’s available.

    • freeMemory: You can use this method to determine the amount of free memory
      that’s available.

    • gc: You use this method to invoke a garbage-collection operation.

Changes to java.lang.System
The System class has been heavily modified as well. There’s no input stream, because
CLDC devices don’t have a traditional console (in fact, there is no way to obtain infor-
mation written to System.out and System.err on most devices, either). The System class
also provides a property accessor called getProperty to obtain information such as the
name of the device host, the character-encoding scheme used by the device, the CLDC
platform version, the MIDP version, and so forth.

     Changes to java.lang.String and java.lang.StringBuffer
     The key difference between these classes in Java SE and the CLDC is that CLDC 1.0 omits
     the methods that take floating-point arguments.

     Changes to the java.util Package
     Table 2-3 lists the supported classes in the java.util package.

     Table 2-3. java.util Classes Supported by CLDC Version

     CLDC 1.0                    CLDC 1.1
     Calendar                    Calendar
     Date                        Date
     EmptyStackException         EmptyStackException
     Enumeration                 Enumeration (interface)
     Hashtable                   Hashtable
     NoSuchElementException      NoSuchElementException
     Random                      Random
     Stack                       Stack
     Timer                       Timer
     TimerTask                   TimerTask
     TimeZone                    TimeZone
     Vector                      Vector

     Changes to Collections
     The Java SE Collections API is a shadow of its former self, but the most-used collections—
     vectors, hashtables, and stacks—still remain.

     Changes to Time Utilities
     The CLDC time APIs are considerably streamlined as well. The notion of date formats is
     hidden entirely, having been wrapped in UI classes provided by the MIDP; the only facili-
     ties provided let you manage instances in time (Date) and time zones (TimeZone). Calendar
     provides the ability to get the current calendar, a millisecond timer, and other utilities.
                                                            CHAPTER 2 ■ SHRINKING JAVA TO FIT   29

Changes to Timer Behavior
Although not part of the CLDC proper, it’s worth calling out the Timer and TimerTask
classes here, as they’re the only MIDP classes in the java.util hierarchy. Drawn from Java
SE, the Timer class lets you schedule a TimerTask to be performed at some time in the
future. As with Java SE, simply subclass TimerTask overriding run, and then use a Timer
instance to schedule the operation. Of course, your MIDlet must be running; for back-
ground wake-up behavior, consider using an alarm (see the “Managing Startup Events
and Alarms” section in Chapter 4).

Changes to the Package
Table 2-4 lists the supported classes in the package.

Table 2-4. Classes Supported by CLDC Version

CLDC 1.0                           CLDC 1.1
ByteArrayInputStream               ByteArrayInputStream
ByteArrayOutputStream              ByteArrayOutputStream
DataInput                          DataInput (interface)
DataInputStream                    DataInputStream
DataOutput                         DataOutput (interface)
DataOutputStream                   DataOutputStream
EOFException                       EOFException
InputStream                        InputStream
InputStreamReader                  InputStreamReader
InterruptedIOException             InterruptedIOException
IOException                        IOException
OutputStream                       OutputStream
OutputStreamWriter                 OutputStreamWriter
PrintStream                        PrintStream
Reader                             Reader
UnsupportedEncodingException       UnsupportedEncodingException
UTFDataFormatException             UTFDataFormatException
Writer                             Writer

         Heavily streamlined, this package omits access to the native file system, but it offers
     limited internationalization through the InputStreamReader and OutputStreamWriter
     classes, which accept an optional string indicating the character-encoding method.

     Introducing Classes in the CLDC
     The key introduction of the CLDC—which found its way into the CDC as well—is the
     GCF, which was described first in the CLDC 1.0 documentation and later provided with a
     migration path to Java SE in JSR 197.
          The GCF provides a unified means to interact with networks over a variety of
     protocols, including but not limited to HTTP, TCP, and UDP. Using a URL schema
     for connection definition, clients obtain instances of a Connection subclass from the
     Connector factory and perform I/O over the Connection subclass. Table 2-5 lists the
     classes available. Chapter 12 describes the GCF in more detail, including examples of
     its use. In addition to these classes, packages such as the MIDP, the Foundation Profile
     for CDC, and the GCF for Java SE include additional connections, such as a connection
     that implements support for HTTP.

     Table 2-5. The Classes Supported by CLDC Version

     CLDC 1.0                            CLDC 1.1
     Connection                          Connection
     ConnectionNotFoundException         ConnectionNotFoundException
     Connector                           Connector
     ContentConnection                   ContentConnection
     Datagram                            Datagram
     StreamConnectionNotifier            StreamConnectionNotifier
     InputConnection                     InputConnection
     OutputConnection                    OutputConnection
     DatagramConnection                  DatagramConnection
     StreamConnection                    StreamConnection

          Besides its importance in providing CLDC applications with a path to communicat-
     ing with the outside world, the GCF provides an object lesson in where Java ME is
     headed: into Java SE. As portable devices continue to become more full-featured, the
     innovations necessary to bring Java to those devices will likely become mainstream parts
     of the Java SE interface.
                                                          CHAPTER 2 ■ SHRINKING JAVA TO FIT   31

Changing the Java Class Library to Fit the CDC
The joy of working with the CDC is that there are no changes to fit the Java SE class hier-
archy—what you see in Java SE is what you get in the Java ME CDC. As previously noted,
however, the CDC is a superset of the CLDC; the GCF is included in the CDC as well.
Table 2-6 shows the classes provided by the CDC in the package.

Table 2-6. Library Additions to the CDC


*Only if the device supports HTTPS.

   Note that the CDC supports HTTP out of the box, as opposed to the CLDC, which
does not include HTTP except as provided by the MIDP.

Wrapping Up
If you take away one thing from this chapter, it’s that the key difference between the
CLDC and the CDC is what’s included in terms of classes. The CLDC contains far fewer
classes than the CDC, which is at parity with Java SE 1.4.2. Notable classes missing in the
CLDC include most of the java.util hierarchy. Specifically, all of the collections except
vectors, hashtables, and stacks are missing. Also, the CLDC provides streamlined time-
management APIs, including a subset of java.util.Date, java.util.Calendar, and
java.util.TimeZone. Finally, it possesses a simplified hierarchy.

         The CDC merges Java SE with the CLDC, meaning that both the CDC and the CLDC
     include the GCF, a media-independent hierarchy of interfaces that provide a factory of
     connections such as sockets, files, or other entities. The CLDC defers the definition of
     which protocols are supported by the GCF to the MIDP, while the CDC requires support
     for HTTP and HTTPS by default.
         Neither the CLDC nor the CDC provides support for GUI development. For that, you
     need a profile such as the MIDP atop the configuration, which is the subject of Parts 2
     and 3 of this book.

To top