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
Interacting with WITS at 28.
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/
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...
The controversy centers around Microsoft's J/
According to Microsoft, having J/
The catch is that applications written under J/
Bitter words have swirled around this issue. David Spenhoff, director of product marketing at JavaSoft, called J/
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/
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/
Despite all the sound and fury, it is possible to see the challenge posed by J/
On the other hand, if J/
J/