BY ROBERT VAHID HASHEMIAN

When Sun Microsystems first introduced us to Java, life as we know it was supposed to be altered dramatically. Being the euphoric guy I am, I immediately envisioned a world filled with Java applications and applets. A world where all software developers lived and worked in peace and harmony under the auspices of Java. A world in which there was no longer a dispute as to which development platform was best. I might be exaggerating a bit, but the point here is that I truly had a great feeling about Java.

Unfortunately, my excitement turned out to be somewhat premature. The fact is that Java has yet to succeed in making a great impact on the computer and information industries, and has yet to generate much revenue for those vendors ardently peddling their Java applications. Despite all the hype touting Java as a serious contender to other application development platforms, such as Visual C++, Java may achieve its greatest success in its original intended market, consumer electronics and embedded systems.

GETTING DOWN TO BASICS
Why has Java attracted so much attention? In a word — interoperability. For decades, we have suffered through scores of incompatible hardware and software platforms and applications, each one working fine by itself but never quite compatible with others in its class. Many companies have attempted to remedy this situation by designing utilities to convert from one format to another. These include import/export programs that convert data formats to be used by different applications, such as Lotus and Excel, and other utilities which can change file formats to make them accessible by different operating systems, such as the unix2dos command of the UNIX operating system. Then there are applications which are offered in several different versions to satisfy the market demand for multiple operating system compatibility. Examples of such applications are Netscape Navigator for Windows, Mac, and UNIX, and Microsoft Office offered for Windows and Mac. Finally, UNIX offers the benefit of running the same type of operating system (albeit different flavors) on different hardware platforms. All this, however, never quite satisfied the ultimate quest for compatible systems until Java came along.

EMBEDDED APPLICATIONS
Java was designed as a uniform and standard method to program the numerous consumer electronics devices in the market. These devices could include video games, VCRs, telephones — even coffee machines. Today, most of these devices are equipped with intelligent circuitry running Real-Time Operating Systems (RTOS). Embedded applications riding on top of RTOSs are implemented to quickly configure, enhance, or troubleshoot these devices programmatically. The only problem is that there has not yet been established a standard method of creating embedded applications.

Each device — with its own CPU and its own RTOS — is equipped with a tailored embedded application, which is incompatible with other devices in its class. Worse yet, the programming of the embedded system has always been approached through the arcane assembly language or even native machine language, thus making it expensive to update or modify. Any new approach that could rein in this chaos and bring the embedded application development up to a uniform standard would have been well received indeed. Java was to address exactly that need.

BAD NEWS AND GOOD
First, The Bad
Java is an advanced object oriented and feature-rich language which can operate on any platform given the right support (run-time) environment. Programs written in Java are compiled into Bytecode, which are then interpreted by the Java Virtual Machine (VM) on the host computers. The crucial step lies in the interpreted nature of the Java language. Unlike the executable program (which is a machine language ready for the CPU to run) an interpreted program must be translated to the specific machine language by the interpreter every time the program is run; in Java’s case this is accomplished by the VM. Interpreted programs, however, have two main drawbacks:

• They run slower due to the translation overhead.
• They require more memory to run, since the interpreter must also be loaded in the memory.

Now, The Good
The good news is that as technology advances, memory modules become cheaper and smaller, CPUs become cheaper and faster, and interpreters become more optimized — making those drawbacks less of an issue. Now using Java (or another similar tool) to program these devices makes perfect sense. The programs can be:

• Easily ported from one platform to another (reusability).
• They can be modified for enhanced functionality (scalability).
• They can be designed to work with each other across various devices (interoperability).

For example, now you can have your coffee machine turned on by calling your home phone and entering a certain code, and you can maintain this functionality even if you change your brewing machine.

Sun Microsystems clearly had a revolutionary vision with Java. The problem was it never really got off the ground.

OF APPLETS AND THE WEB
This was not destined to be Java’s final stop, however. By 1994, the WWW had started to push its entry into the Internet domain with much fanfare, and Sun Microsystems — realizing the inefficiencies of the early Web browsers — had an idea to bring Java into the browser arena. After all, the browser was a platform in its own right, and given the appropriate VM, it could support Java applications, or as they came to be known, applets. At the same time, a movement began to take shape under the leadership of Sun, declaring Java as the definitive solution to the platform wars. Again, given the right VM, a Java application could be utilized in any platform, thus making the promise of platform independence a reality.

On the surface, such a capability would be a dream come true. But, in the real world there are tradeoffs, and Java is no exception. As I already mentioned, Java applications run slower and require more memory than native applications. But there’s more. Since Java needs to operate in a variety of environments, it must make compromises in its ability to utilize every feature of every platform that it runs on. Therefore, Java applications may not be as efficient, comprehensive, or stylish as their native counterparts.

THE GUI
Take GUI as an example. The Java graphical interface must be able to produce the same look and feel under MS Windows, X-Win-dows, Motif, and Macintosh — a formidable task, considering that these platforms have as many differences as they do similarities. So, the Java applications often end up with coarse and crude graphics in contrast to the refined and sophisticated GUIs produced by their native counterparts. Also, Java cannot be expected to be compliant with every advanced service offered by the underlying platform. For example, OLE, an important technology used by MS Windows applications, is not supported by Java.

CROSS-PLATFORM INDEPENDENCE
Another sticky problem with Java stems (ironically) from its main appeal, cross-platform independence. To achieve this independence, Sun has had the unenviable task of drumming up industry support for Java through licensing agreements, while at the same time restricting the licensed companies from making any proprietary changes to Java that would make it incompatible on other platforms. The latest wrangling between Sun and Microsoft is over this very issue, where Sun is accusing Microsoft of having broken the licensing agreement by introducing Windows-specific features and not supporting some key features of Java. The promise of lucrative Java products that run on the desktop is also debatable. Today Java applications account for an insignificant share of the software market, with most of the revenues realized by companies who make Java development tools. Sun itself draws almost no revenue from Java.

LOOKING AHEAD
So what does the future hold for Java? There are several possibilities. We may end up with a dominant platform once the dust of the platform wars has settled. Windows NT is clearly gaining market acceptance and flexing its muscle in areas where UNIX used to be the dominant player. Meanwhile, UNIX retains plenty of strongholds. With prices in decline, UNIX better compete with Windows. Regardless of who the winner is, Java must then compete with the native development applications on a particular platform, giving it little chance to flourish. UNIX and Windows should maintain their mainstream position. As disconcerting as it may sound, we may see different flavors of Java emerging to fully accommodate their respective platforms. In that case, Java would have to compete with the native development tools and applications based on its merit and not on platform independence. That would be a hardwon accomplishment, considering the wellentrenched status of longfavored development tools such as Visual Basic and Visual C++. Or, Java may continue to push its cross-platform benefits but still have to grapple with the drawbacks associated with its interpreted format.

SOME OPTIONS
Other development tools and components may emerge with crossplatform characteristics. Microsoft’s ActiveX technology, an indirect competitor to JavaBeans (re-usable Java modules), is starting to draw some attention. ActiveX allows software components on different platforms to communicate with each other. This is not exactly a portable solution, but it may be a glimpse of things to come.

Finally, a whole new line of hardware platforms with Javaoptimized CPUs could be on the horizon. Several companies, including Sun, are working on Java processor chips which promise to run Java applications at much faster speeds than are possible today. Java would certainly be the preferred development tool on such computers, but the jury is still out on whether these systems will ever see the light of day or if they would be able to successfully compete with the well-established platforms already on the market.

I believe that Java’s future truly lies in the embedded application industry, which Sun is pursuing with the EmbeddedJava and PersonalJava environments. This market has not had a clear call for standardization and is ripe for Java to make a strong and lasting impression. We all liked those cute Java applets running on our browser screens, but the novelty has long since worn off. Java must now prove itself a worthy alternative to its native counterparts. A battle is surely brewing ahead. For more information on Java, visit the definitive Java site at java.sun.com.