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:

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.

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.

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.

Summary
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.

Resources
1. PersonalJava 1.0 Specification. Sun Microsystems, Inc.
http://www.javasoft.com/products/personaljava/spec-1-0-0/personalJavaSpe...
2. Inferno: la Commedia Interattiva. Lucent Technologies, Inc.
http://inferno.lucent.com/inferno/infernosum.html
3. Java Developers Journal. "The Developers of Inferno." Volume 1, Issue 4.
4. Inferno Programmer's Guide. Lucent Technologies, Inc. Murray Hill, NJ. 1997.