HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

Personal Java
PersonalJava™ is a new Java Application Environment for network-connectable applications on personal consumer devices for home, office and mobile use. It is designed specifically for resource limited environments.

PersonalJava is designed to be highly scalable and configurable while requiring minimal system resources - a key factor in embedded software applications. It is targeted at developers writing applications for consumers who may not be computer-savvy. PersonalJava supports robust user interfaces and the downloading and execution of applets. These applications, like the JavaCard, are upward-compatible and will run on "enterprise" Java platforms.

Inferno™ is an operating system for creating distributed services and is intended for use in a variety of network environments, including hand-held devices, set top boxes and inexpensive networked computers as well as traditional computing systems. It creates a standard environment for applications and identical application programs can run under any instance of this environment, even in distributed fashion, and see the same resources. The system architecture is constrained only by the desired markets and available interconnection and server technologies, not by the software.

To some they are "gadgets." To others they are "gizmos." To many, gadgets and gizmos are nothing more than big-boys' expensive toys. Nevertheless, "toys" not unlike Dick Tracy's Wrist Communicator, or James Bond's combination cellular phone/fingerprint analyzer/car remote control/security scanner, are no longer only in Hollywood prop rooms or sci-fi writers' imaginations.

Yes, we are beginning to see an emergence of a wide range of gadgets and gizmos, personal consumer devices or information appliances as they are often called. Today's personal consumer devices, with the declining cost of electronic components and stiff competition in the marketplace, promise to be in the realm of affordability to the masses. Compared to the cost of desktop computers, some consumer devices are very inexpensive. We're talking about hand-held personal digital assistants, set-top boxes, game consoles and smart phones. Some manufacturers have already introduced products or prototypes of these devices with street prices in the range of a few hundred dollars.

Consumer devices introduce a new computing model with the potential for being distinctly different from the traditional desktop computing model that we've grown accustomed to. This new computer model presents many new opportunities and challenges for today's application developers. The target devices for our applications have many special requirements.

For example, their screens, or displays, can be nothing more than a small LCD panel capable of displaying only a few lines of text. Or they can be as big as your TV set. Or somewhere in between.

What about the user interface? Does the device have a mouse? A touch-screen? An IR remote? A keyboard?

What about the application environment? The development tools? The operating system?

These are just simple examples of what an application developer must take into consideration when designing and developing an application for consumer devices. A combination of two of the most important technologies introduced in the past few years helps you, the application developer, address these challenges as real opportunities.

Introduction to PersonalJava and Inferno
The minds at Sun Microsystems - the ones responsible for the Java revolution - have introduced a Java Application Environment (JAE) designed for personal consumer device applications.

"PersonalJava" is a Java API and Java Application Environment for networked applications running on personal consumer devices.[1] PersonalJava enables these devices to run Java programs, giving developers a direct link to providing applications for these devices.

The innovators at Lucent Technologies' Bell Labs - the same Labs that created Unix, C and C++ - are also providing technology for enabling distributed, network applications to run across multiple platforms and networks. Inferno is a small network operating system "intended to be used in a variety of network environments; for example those supporting advanced telephones, hand-held devices, TV set-top boxes attached to cable systems and inexpensive networked computers."[2] Inferno enables these devices to use resources scattered across any network, giving application developers the ability to create distributed applications.

The combination of these technologies gives application developers the necessary tools for designing, developing and deploying sophisticated, intelligent, usable real-world consumer devices.

The PersonalJava JAE
In late September of 1997, JavaSoft released the 1.0 specification for the PersonalJava JAE. PersonalJava is specifically targeted for networked applications on personal consumer devices for home, office and mobile use. It consists of a Java Virtual Machine and core and optional APIs designed for the resource-constrained environments and special requirements of consumer device applications. It can be considered a subset of Java in the sense that PersonalJava applications are upward-compatible to standard Java, defined by the JDK. On the other hand, it is also a superset of Java since it includes features, such as additional APIs, that are common to consumer devices.

PersonalJava is designed to benefit application developers in the following ways:

  • PersonalJava-based applets also run in a JDK 1.1 applet environment and are compatible with JDK 1.1 packages supported by PersonalJava. This gives developers the ability to write applets for PersonalJava that can use the JDK 1.1 applet features when running in a JDK 1.1 applet environment.
  • The PersonalJava environment can also run a large proportion of the applets written for the JDK 1.0.2 and the JDK 1.1.
  • PersonalJava can adapt to the many input and output mechanisms used by consumer devices, including remote controls, television output and touch screens.
  • PersonalJava requires less memory than the JDK 1.1 in terms of the Java system itself and of runtime requirements. The PersonalJava Virtual Machine and class libraries are designed to fit within 2 megabytes of ROM and execute in 1-2 megabytes of RAM. This makes PersonalJava highly scalable and configurable while using minimal memory.
  • PersonalJava reduces time-to-market for consumer devices with the portability, flexibility and code reuse attributes inherent to Java.
  • In the relatively short time that the PersonalJava specification has been publicly available, there are already a number of manufacturers and software developers using it for products such as hand-held computers, set-top boxes, game consoles, mobile devices and smart phones.
The Inferno Network Operating System
Even before Inferno's first commercial release in March of 1997, it was compared to and seen as a rival to Java. The two technologies do address some of the same issues, both in similar and distinctly different ways, but they are really not competitors[3]. There are, in fact, many aspects of Java that find complements within Inferno. Initially, Java was designed for the very market where Inferno is finding itself, that of small consumer appliances and devices.

Inferno is a complete, full-service operating system that includes a real-time kernel, a concurrent programming language (Limbo), a virtual machine (Dis) and a communication protocol (Styx). It provides many important features expected in an operating system designed for applications running on a wide range of consumer devices. Inferno includes built-in security, network independence, multithreading and multi-processor support, heap and stack management, interpreted and JIT (just-in-time) compilation, graphics libraries and support for IR input devices.

Inferno's definitive strength lies in its portability and versatility across several dimensions:

  • Portability across processors: It currently runs on Intel, SPARC, MIPS, ARM, Strong- ARM, HP-PA and AMD 29K architectures and is being ported to others. This gives an application programmer the confidence that an application written for Inferno will run on the popular architectures being used in consumer devices.

  • Portability across environments: It runs as a native operating system on small devices and also as a user application (in Emulation mode) under Windows 95/NT and Solaris. In all of these environments, Inferno applications see an identical interface.
  • Distributed design: an application can establish the identical environment at the client and at the server and each may use the resources of the other. Through the communications facilities of Inferno's runtime system, applications can be designed to be dynamically distributed between client and server, multiple servers or even multiple clients.
  • Minimal hardware requirements: It runs complete applications on machines with as little as 1 MB of memory and does not require memory-mapping hardware.
  • Dynamic adaptability: Applications may, depending on the hardware or other resources available, load different program modules to perform a specific function. For example, a video player application might use any of several different decoder modules.
The purpose of most Inferno applications is to present information or media to the user; thus, applications must locate the information sources in the network and construct a local representation of them. Inferno is designed to isolate the mess of network hardware and protocols from the application programmer. Inferno's design has three principles:
  1. Most resources are named and accessed like files in hierarchical file systems.
  2. The disjoint resource hierarchies provided by different services are joined together into a single, private, hierarchical namespace.
  3. The Styx communication protocol is used by the system to access these resources, whether local or remote. This gives an application uniform acccess to resources, whether local or remote.
Many service providers are looking aggressively to expand their reaches by providing a vast array of services and media. This includes the giant industries of telecom, Internet and cable providers. In this arena, however, there are diverse network hardware and protocols, including POTS, ISDN, ASDL, ATM, broadcast TV, cable TV, digital TV, satellite, the Internet, etc. The destination of the media and services that must traverse this mélange of acronyms is the variety of consumer devices we have been talking about.

In less than a year since its first commercial release, Inferno has garnered partnerships with a large number of OEMs and ISVs. These partners are using Inferno in a variety of consumer devices, including smart phones, set-top boxes, game consoles and mobile devices, as well as a number of other non-consumer devices such as network elements and servers.

Figure 1
Figure 1:  General Inferno architecture

The Vices of Consumer Devices
As we've already discussed, consumer devices present many new opportunities and challenges for today's application developers. Some of the most significant of these challenges are memory and display constraints and the varying types of input and output sources.

Where's the Memory?
Consumer devices typically do not have the large amounts of RAM or ROM required by most of the software that we run on our desktop systems. It is not unreasonable for a device to have at most 1MB of RAM and 1MB of ROM available for the operating system, the applications and user data.

You Call That a Screen?
Displays vary significantly from one type of device to another and they rarely have the capabilities of a desktop's SVGA monitor. It doesn't seem all that long ago that a laptop's display looked more like a washed-out watercolor painting than a computer's screen. We've seen some tremendous advances in the quality of smaller displays in just the last couple of years. With that, though, comes our insatiable thirst to make them even smaller. How many clowns can you fit into a Volks- wagen Beetle? Probably more than the number of pixels that fit on the display of some small consumer devices.

No Mouse? No Keyboard? What Do I Do?
The method by which the user will interact and interface with the device and the applications may not be via a mouse and keyboard; the device may have a touch screen, IR remote control, some kind of small keypad or voice recognition.

The PersonalJava and Inferno Solution
The combination of PersonalJava and Inferno solves many of the problems developers face when developing applications for consumer devices.

Lean and Mean
Amid the many praises of Java, one of the loud complaints has been its rather large memory requirements. Most typical JDK 1.1 implementations require 8, 16 or more MB of memory. PersonalJava, however, was designed with the more modest memory requirements befitting a consumer device. The intent, as stated in the specification, is that the Java Virtual Machine and class libraries fit in 2 MB of ROM and execute in 1-2MB of RAM.

This does not take into account the operating system or other system requirements. The Inferno operating system is very small and itself requires less than 1MB. So, in practice, it seems that 4MB of total memory is the lowest possible and 6 to 8MB would be recommended for most applications.

Although recently we have seen a dramatic drop in the price of the memory typically used in consumer devices, the fact remains that the less memory that is required, the cheaper the device can be manufactured. This is especially evident when you consider that some of these devices will be manufactured in relatively large quantities. For example, if a manufacturer can shave $20 off the cost to make a single set-top box by limiting the amount of memory, that translates into $20,000,000 savings in the production of 1,000,000 units. They must walk a fine line when determining how much memory a device needs to be useful verses the cost of production.

Granted, most of us don't care much about the manufacturing costs of millions of units. What we do care about is the hardware specs of the device that we want to run our application on. It may mean that we have to approach writing our applications very differently if the device has 1MB versus 4MB of memory.

Inferno, in particular its virtual machine (named Dis), was designed with the flexibility of providing a multi-language programming environment. Applications written in Inferno's native programming language, Limbo, can run simultaneously with PersonalJava applications.

Figure 2
Figure 2:  Inferno on a Solaris workstation running
two Java apps (union and drawingPoly), as well as a Limbo Web browser

One of Limbo's many features is portability[4]. Limbo programs, like Java programs, are compiled to a hardware-independent binary image (bytecode) for execution in Inferno's virtual machine. Like Java, Limbo can be interpreted or compiled on the fly for portable execution, use garbage collection for memory management and support the Unicode character set. For Limbo, though, concurrency and inter-task communication are intrinsic components to the language and virtual machine.

Limbo is a procedural language that uses the concept of "modules" with separate interfaces and implementations. A typical Limbo application is composed of a set of dynamically interacting modules. The flexibility of the module model contributes to the compactness, efficiency and adaptability of Limbo applications.

Size Doesn't Matter
Small screens do not mean that we are returning to the world of pre-GUI days. Users still expect and demand the aesthetically pleasing, graphical point-and-click interfaces. For some devices, however, this just won't be practical. Another JAE, EmbeddedJava™, is better suited for devices with even greater constraints.

PersonalJava addresses this issue by modifying some of the API packages, in particular java.awt. For example, the Component.setCursor() method may ignore the specified cursor since some platforms may not support cursors and others may limit the types of cursors displayed for usability reasons.

It may not make sense on some devices to have a general-purpose window manager that allows a user to manipulate overlapping windows, such as resize and move. PersonalJava implementations might not support the creation of a Frame or Window beyond the "root" window.

Additionally, PersonalJava provides a special API for performing double buffering (for platforms that support it) to make painting and updating graphics appear smoother. There are ways to accomplish this by explicitly creating an off-screen image, drawing into it and then using the drawImage method to display it. However, since this can take large amounts of memory, it may not work on devices with limited memory. (Since this can have benefits beyond just consumer devices, it is likely that it will be included in a future version of the JDK.)

PersonalJava provides a new method, isDoubleBuffered, for class Component:

public boolean isDoubleBuffered();

A return value of true indicates all drawing performed by the paint and update methods are double buffered.

Through Inferno's namespace, where all application resources are represented as a hierarchical file system, even devices such as the display device (console) can be imported and exported across the network. They can be dynamically loaded and unloaded, depending on the application's needs.

"Look, Ma! No Mouse!" For the last 30 years or so, a computer has been synonymous with a keyboard of some type. However, many of today's consumer devices don't have a keyboard or if they do, it's some convoluted mixture of shift/control keys.

In conjunction with traditional GUIs, some kind of pointing device is generally required, whether it's a mouse, trackball or pen. Yet it isn't too likely that we'll see a mouse port for a cellular phone. In mouseless environments, the users typically can navigate from one on-screen component to another using keys or buttons on the device. For example, after navigating to an on-screen button component, the user might press the Go key on a remote control to indicate that the on-screen button is to be "pressed."

PersonalJava provides additional APIs for specifying ways of interfacing with components in a mouseless environment The API includes four interfaces in the java.awt package that allow developers to make it easier to adapt to mouseless environments:

public interface NoInputPreferred {}
public interface KeyboardInputPreferred {}
public interface ActionInputPreferred {}
public interface PositionalInputPreferred {}

Inferno enables an application to dynamically load the support modules for the input device in use. For example, when an application is running on a set-top box that uses a remote control, it can load the IR interface module; when it is running on a desktop or a system that uses a keyboard for input, it can load a keyboard IR simulation module.

Figure 3
Figure 3:  Inferno running in a set-top box environment

So, whether they are just "gadgets" or "gizmos" to you, the emerging market of consumer devices presents many exciting opportunities for application developers. With these opportunities, we must take into consideration their distinct, if not peculiar, application requirements.

The PersonalJava JAE is sure to put the Java trademark on a wide range of consumer devices. Its design gives application developers the ability to add another verse to the "Write Once, Run Anywhere" mantra.

PersonalJava applications running in Inferno can take advantage of Inferno's extensive features, such as security and network independence. Through Inferno's native programming language, Limbo, application developers can easily tap into the advanced low-level features of Inferno.

The strengths of Inferno and PersonalJava can open up the possibilities for application developers to tap into the growing and lucrative market of lower-cost consumer devices. These applications can give users easy access to a world of remote information and resources.


  1. PersonalJava 1.0 Specification. Sun Microsystems, Inc.
  2. Inferno: la Commedia Interattiva. Lucent Technologies, Inc.
  3. Java Developers Journal. "The Developers of Inferno." Volume 1, Issue 4.
  4. Inferno Programmer's Guide. Lucent Technologies, Inc. Murray Hill, NJ. 1997.
About the Author
Steven P. Frank is a member of the technical staff at Lucent Technologies/Bell Labs in Murray Hill, NJ, working in the Inferno venture group for the past year. Most recently, he has been working with the Java Integration team responsible for PersonalJava support in Inferno. Steven can be reached via e-mail at [email protected]

All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.