In California's Silicon Valley, understating the value of a product is about as rare as an eight-hour day. But when Sun Microsystems unleashed Java on the world, even Scott McNealy--Sun's wisecracking, far-from-humble leader--didn't manage to fully convey just how big the Java industry would become. He didn't convey it because neither Sun, nor its partners, nor practically anyone else could have imagined it. But from third-party development products like Symantec Café and IBM's VisualAge ("IBM's unrivaled commitment to Java continues..."), to commercial Java-based applications that might actually make developers money or even advance the frontiers of science, Java has proven to be a very big deal--one that some would characterize as revolutionary.

Consider, for example, the program running in demonstration form on Sun's own Web site. Called WITS (Web Interface for TeleScience), the program is intended to help scientists around the globe view data from the Mars Pathfinder mission and collaborate in selecting Martian features for the Rover--the project's robotic vehicle--to examine. If all goes well, WITS will be fully operational for the second Mars mission in 2001. Meanwhile, a WITS simulation is already available for the viewing at graham.com wits="">. To use it, you either install a Marimba Castanet tuner—a one-time operation that enables repeated use of WITS without further downloading—or, you can download the applet itself. The program begins with two views, which are meant to be seen side by side in separate windows, with identical tool bars for both. The "panoramic" view shows what the terrain looks like overhead, color coded to show relative height as well as the Rover's location, and user-specified way points and targets. You can change the direction of the view, rescale it, as well as add targets, way points and hazards—locations that Rover should not drive through. The accompanying "mosaic" view features actual pictures of the terrain patched together in mosaic fashion to give a reasonable approximation of what the Rover "sees." graham.com>

Interacting with WITS at 28.8 Kbps requires some patience. I could rescale the mosaic view, for example, in less than 10 seconds. At other times, it felt like running a Windows 95 program on a 386 machine. But considering that you are interacting with a demo program residing at the Jet Propulsion Laboratory (JPL) in Pasadena, WITS is pretty remarkable. And what's the advantage of Java here? In part, of course, it's giving broad access to an application that resides on a single server. In addition, JPL reported what it considered a surprisingly fast turnaround for development and deployment.

Java in Berkeley

Another science-related Java application is under development at Lawrence Laboratory (LBL) , the sprawling lab perched above the University of California at Berkeley campus. Chris Timossi, a computer systems engineer at LBL, along with another developer and a project manager, is programming a user interface in Java. The interface will be used by researchers to control instruments will that direct a concentrated beam of light emitted by three electron accelerators—a linear accelerator and two ring accelerators: as part of a project LBL calls the Advanced Light Source. The light will be used in diverse applications, including materials science, crystallography, x-ray microscopy and lithography. Timossi's goal is to produce an interface that is both sophisticated, yet straightforward enough for a non-programmer to master. It will support two monitors, enabling scientists to both analyze their data and control the beam line.

"We started doing the clients in C++, but we didn't see many good tools for building user interfaces, at least none that I really liked," says Timossi. "With Java there's a lot of resources available and the language is a simpler to use." Timossi settled on Symantec Café, a technology he felt was far ahead of the others for building Java applets, and started programming. He might have used Visual Basic except that he was developing under Solaris and Sun rather than on Windows. Because Symantec Café itself doesn't run under UNIX, Timossi is developing on a PC even though he will deploy on the workstation.

Strictly speaking, the applications are intranet based, but not in the traditional sense. Typically, a Java applet is downloaded from a server to a client, where it runs on the user's behalf. But Timossi's applets run on the client with no HTML server involved. Instead, the applet gets its data from the server via Corba calls. "We have to be very careful when we talk about server and client here," says Timossi. "Our client is Sun's Enterprise 3000—a server class machine, and we use about four smaller SPARCserver 5s as servers. This is a case where the servers are actually less powerful than the client machines, but are themselves directly tied to the hardware. A Java applet that is running on the Enterprise 3000 gets what it needs from these various SPARC 5s, but the Java applet and the browser are all local to the Enterprise 3000."

Although Timossi likes Java as an interface development platform, he doesn't think it's ready to replace C++ at the back end. "We have to talk to C programs that in turn talk to the hardware, and Java is just not very good at talking at that low a level," he says. "In Java, there are ways to link in C applications or subroutines, but it's kind of messy, so we're still doing the Corba servers in C++." In addition, Sun deliberately designed Java without memory pointers in order to make the Java virtual machine a more secure environment. But without the ability to affect CPU registers, Java's ability as a low level language is limited.

"Java has made good progress in becoming a general purpose programming language, as opposed to just making little balls spin on browsers," Timossi says. "Some of the things that make Java unsuitable as a system programming language—like the absence of pointers—have made it more user friendly. Plus, Java's syntax is a little easier than C++, and it is multiplatform, which is convenient." For this reason, says Timossi, universities are teaching Java as a first language, much the way Pascal was taught years ago.

Elegance and functionality

The more typical use of Java is in the commercial market: companies employing Java to make money. For example, Richard Paymer, chief technology officer of a startup called SceneWare Corp., (Walnut Creek, Calif.) is using Java to develop an application that will allow database data to be viewed graphically over the Internet. Like Timossi, Paymer also cites Java's simplicity in comparison with C++, but unlike Timossi, has not yet bumped into Java's limitations.

"The traditional thing in computer languages is elegance versus sheer number of constructs," he says. "In the old days, IBM's PL/1 let you do everything—no matter what you wanted to do, there was a statement that let you do it. That's been the C++ approach. The other extreme has been elegant languages like Pascal. But those were so crippled in terms of what you could get done, that they never got general industry acceptance. Somehow Java has managed to give you the power while retaining the elegance."

Paymer also notes that Java's virtues on the server side have been overlooked. For example, he wrote an applet that acts as a traffic copy to control data sharing among clients—an application that he would have previously written in C or C++. "The first time we told people we were dong this, they looked at us like we were crazy. But now I'm seeing lots of other companies following suit because they realize Java's a great language for server development. The reason is that the Java designers thought from the very beginning about things like multi-threading and network communication libraries, which you always need in a multi-threaded applications. They did a good job of defining the objects that we need to do that."

Paymer has run into some overhead problems associated with the Java virtual machine. He cites one case in which he was trying to write code for a multi-threaded environment. "We use a parameter called 'synchronize' in order to make the code 'thread-safe,' that is, to exclude other synchronized methods from executing at the same time. But from benchmark testing, we've discovered that any method that's declared synchronized takes about 60 times longer to initialize than one that isn't synchronized. That means you can have synchronization in theory, but because it's so expensive to use, you generally don't use it. But JavaSoft has said that over the next few months they will completely remove the penalty for synchronization. And as Sun has been good about sharing its technology, I think we'll see the improvement in all the relevant virtual machines."

Perhaps the most unusual aspect to SceneWare's development effort is choice of development tools. Each of the three principal development engineers on the project each works with a different environments: Symantec Café, SuperCede (from SuperCede, Inc., a spin-off of Asymetrix Corp.), and Paymer's personal favorite, the Sun's Java Development Kit (JDK). "All three systems have completely compatible classes," he says. "The compiled code runs transparently across our machines, which is great."

100 percent Java vs. Windows-centric Java

While developers are happily developing in Java, a segment of the Java industry is unhappily feuding with each other. A controversy has erupted involving two visions of the technology, which Peter Wayner of the New York Times has called "a great public relations war." On one side is Sun, with its 100% Pure Java initiative—and its stress of platform-independence. On the other is Microsoft, which Wayner says, "seems to be using its standard Borg-like strategy of embracing and extending. When someone else comes up with a good idea, Microsoft will adopt the technology and then add in enough good extensions...that just happen to require Microsoft's OS."

The controversy centers around Microsoft's J/Direct, an extension of Microsoft's Java Virtual Machine that runs on Windows 95 and Windows NT. Microsoft argues that J/Direct offers a clear advantage for developers targeting the Windows environment. Developers can make direct calls to the Win32 API rather than having to go through Java's middleware API—which Microsoft calls an "extreme subset" of Win32 functionality. Specifically, J/Direct affects system calls made outside of Java to system libraries and Dynamic Link Libraries (DLLs).

According to Microsoft, having J/Direct make the call rather than Java middleware simplifies the process through automatic garbage collection (that is, the freeing of unused memory) and the automatic handling of data type conversion, such as pointers, strings and structures. Microsoft claims that J/Direct will enable Java programmers to build applications that were either impossible to build otherwise or were commercially impractical. These include multimedia applications, applications that are tightly integrated with existing applications, as well as scalable "industrial strength" applications.

The catch is that applications written under J/Direct guidelines won't work under other operating systems—most notably, UNIX. One of Java's biggest advantages, of course, is platform independence. The whole idea of a virtual machine is that it provides a universal environment for executing Java applets regardless of where the virtual machine runs. In the Java "democracy," vendors were responsible for building virtual machines for their own operating environments, and a "well behaved" virtual machine would not introduce any platform dependencies. And so from the Java community's point of view, Microsoft is not exactly being a good citizen.

Bitter words have swirled around this issue. David Spenhoff, director of product marketing at JavaSoft, called J/Direct a trap and just one more attempt on the part of Microsoft to lock Java applications into Windows, defeating the purpose of Java. George Paolini, JavaSoft director of corporate marketing, said that Microsoft's only motive was to lock developers into the Win32 API, but predicted the move would backfire because developers would prize interoperability over direct access to Win32. In the publication Sun World he said, "It's a classic mistake high technologies go through: milk the cash cow instead of adapting to the new paradigm." He compared Microsoft's move to that of Wang Laboratories—an early maker of dedicated word processors—trying to hold off the PC.

But Microsoft was having none of it. Microsoft product manager Tom Johnson said in Sun World that "developers are telling us that they are more productive in Java than in C, but they don't have the fine grain control that is provided with J/Direct."

Cornelius Willis, Microsoft's director of platform marketing, told the San Jose Mercury News: "We're offering people a choice. If developers want to write a cross-platform application that works at the lowest common denominator, that's their call. If they want to write an application that takes advantage of the power of Windows, we'll support that too." Making an indirect reference to the newly democratized Eastern European countries, Willis said, "Our message to the Java community is to come over the wall and make some money; the security police are gone and you don't have to drive a gray car for the rest of your life." Willis also made the case that J/Direct would make more money for developers and that money was better than platform independence. "Sun has a religious position on purity. But developers need to take advantage of the strongest environment. You can't eat purity."

Despite all the sound and fury, it is possible to see the challenge posed by J/Direct in something other than religious terms. Indeed, the decision of the marketplace will send a loud message to both camps. If J/Direct becomes popular, then the message to Java tools developers is that improved Win32 support matters more than platform independence. And the challenge then is to build a Windows virtual machine that incorporates J/Direct advantages, while maintaining platform independence.

On the other hand, if J/Direct goes ignored, then platform independence really is Java's crowning virtue and developers will seek it, even at some inconvenience. Indeed, the situation in some ways resembles vendor "improvement" to language compilers, such as COBOL or Fortran, that did not adhere to the industry recognized standard. Use the commands and your code might be easier to write, but you would marry yourself to that vendor's compiler technology.

J/Direct also demonstrates the calculated risk Sun made in putting Java out in the public domain. The company has had great success with this with other software technologies, most notably, NFS. Clearly, the public availability of Java contributed much to its burgeoning popularity: it's hard to imagine programmers like Timossi and Paymer embracing Java were it a proprietary language. But the move has also opened Java up to competitive pressures, and no company puts on the pressure like Microsoft. For tools developers trying to capitalize on Java, the heat is on. But that same competitive pressure has given developers a lot of choices—including the ability to use three different development tools on the same project. Behind the name calling, the Java industry is in great shape.