The J2ME Generic Connection Framework
While Windows running on X86 processors still commands more than 90% of the desktop market and more than half of the server space, the embedded device market is far more diverse. The small device ecosystem contains hundreds of different processors and dozens of operating systems. To some extent this is a reflection of the diversity of the devices themselves. Theres not all that much difference between a laptop and a desktop and a blade server. They e pretty much all rectangular boxes with the same basic hardware, give or take a couple of ports. By contrast, embedded devices cover everything from cell phones to PDAs to watches to car ignition systems to hotel door locks to televisions to jewelryvery different devices with very different needs. A CPU and operating system that work well for an iPod may be completely unsuitable for the hard real-time requirements of avionics controls. Still, even among similar devices such as cell phones, the market is far more diverse than it is in personal computers.
Javas platform agnosticism makes it an obvious choice for the diverse embedded marketplace. It offers developers the hope of writing one piece of code that can run more or less reliably on many different vendors hardware. The fit is not always perfect, but its better than anything that has come before.
There are over two and a half billion Java-enabled devices on the planet today, and about 75% of those are embedded devices. These devices vary widely in capability. On the high end, an iPod might have a 60-GB hard drive and dual 100-MHz CPUs. On the low end, a hotel door lock might have no disk space, a few kilobytes of memory, and an 8-bit 1-MHz processor. In between, a cheap cell phone might have 300K of memory and a 30-MHz processor. Weak battery power and inadequate heat dissipation exacerbate these limits. While it might be possible to put a 1-GHz processor in a cell phone, you couldn power it for more than a few minutes without running out of juice and burning a hole in the users pocket.
Even at the high end, embedded devices are very limited compared to modern PCs. In particular, the memory requirements can be extremely tight. While desktop and server programmers stopped worrying about memory footprint years ago, embedded programmers still find themselves making gut-wrenching choices between functionality and features. Every extra byte carries a cost that must be weighed. Every class must be considered for the trade-off between programmer convenience and end user space. For instance, to a micro-programmer the Java habit of creating a new class for every tiny variation of an exception seems extremely wasteful.
Simply put, Java 2 Standard Edition (J2SE) is too big for most small devices. The sheer number of classes in the Java class library can be an obstacle to embedding standard Java. Consequently, Sun, Nokia, Motorola, and others have defined a different, incompatible version of Java tailored to the needs of small devices, called Java 2 Micro Edition (J2ME). In fact, theyve defined several variants and versions for devices of different sizes and capabilities. At the very bottom is the Connected Limited Device Configuration (CLDC) 1.0. This platform is designed for battery-powered, intermittently connected devices with as little 160K of memory, most of which has to be used by the VM itself. The Connected Device Configuration (CDC) is targeted at slightly larger devices such as PDAs and settop boxes. These devices have at least 2 MB of memory and faster and more reliable network connectivity. The Mobile Information Device Profile (MIDP) adds features on top of a basic CLDC or CDC implementation, with an emphasis on user interface classes. The different profiles provide different subsets of and additions to the standard Java class library.
This is not the Java you know and love. The language is the same, but the library is quite different. In particular, it is much smaller and comes with greatly restricted functionality. Most programs are implemented as MIDlets rather than standalone applications with main( ) methods. Most interestingly for the purposes of this book, the I/O classes in J2ME are not just cut-back versions of the classes available in the standard java.io package. Instead, they are a completely different set of classes in the javax.microedition.io package, which is not available in regular Java. This is called the Generic Connection Framework (GCF).
The GCF offers two interfaces, five exceptions, and 11 classes from java.io. More specifically, it includes:
- The InputStream and OutputStream abstract classes
- The ByteArrayInputStream and ByteArrayOutputStream classes
- The DataInputStream and DataOutputStream classes
- The DataInput and DataOutput interfaces
- The PrintStream class
- The Reader and Writer abstract classes
- The InputStreamReader and OutputStreamWriter classes
- IOException and four subclasses: EOFException, InterruptedIOException, UnsupportedEncodingException, and UTFDataFormatException
However, thats all. Other classes from java.io and java.net are completely absent, and even the included classes are set up differently than they are in regular desktop Java, to avoid an explosion of classes for each different kind of stream.
These classes may not have all the methods you e accustomed to, either. For instance, in CLDC 1.0, DataInput and DataInputStream are missing readLine( ), readFloat( ), and readDouble( ). DataOutput and DataOutputStream are missing writeFloat( ) and writeDouble( ). DataOutputStream is also missing size( ). PrintStream is missing all the methods that print doubles and floats. CLDC 1.1 devices contain the floating-point methods, though they e still missing the deprecated methods, such as readLine( ). The Reader and Writer classes are complete, but they don support all the encodings desktop Java versions do.
The CDC does provide a full implementation of java.io and java.net at the level of Java 1.3 for CDC 1.0.1 and 1.4 for CDC 1.1 (java.nio is still omitted). It also includes the Generic Connection Framework.
