PALO ALTO, Calif. — Java isn't cutting it in scientific computing, a group of prominent engineers has charged.

The engineers have banded together to form the Java Grande Forum, in a bid to get Sun Microsystems Inc. to correct what they say are serious deficiencies in the programming language. Specifically, they claim that Java falls short in its handling of floating-point calculations, arrays and complex numbers. Such lapses could affect engineering applications ranging from computer simulation to signal processing.

"This is not just for supercomputing," said Geoffrey Fox, founder of the Java Grande Forum. "It's critical for the regular engineer. It affects Java in classic, sequential applications that engineers do on the desktop."

Sun is aware of the group's efforts. "We absolutely do take them seriously and we intend to address them," Java inventor James Gosling of Sun told EE Times.

Sun is already at work on one key revision: It will change the Java spec to permit the use of extended precision in the evaluation of floating-point expressions. However, Sun doesn't plan near-term action on most of the other issues raised by the group. "The problem is that there's so much other stuff to do, it's hard to get to it as quickly as some would like," Gosling said.

Sun's actions seem to be eliciting a wait-and-see response. "In general, Sun has been positive and I'm optimistic," said Fox. "Until the crunch comes, we can't say if they'll make the necessary changes. The real issue is whether Sun can afford to make all the changes for a field such a science and engineering, which is a rather small slice of their revenue stream."

Less sanguine is William Kahan, a professor of computer science at the University of California at Berkeley who is best known as the father of the IEEE floating-point standard, adopted in 1985. "I don't think Sun is taking the proposals seriously," Kahan said. "I doubt that they regard anything to do with floating-point as a serious issue, because Java is really aimed somewhere else."

At the heart of Java Grande's quest are a series of arcane technical issues related to the way Java handles numerical calculations. "One deficiency has to do with complex arithmetic," said Dongarra. "There's no complex arithmetic that's native within the Java language. In languages like Fortran and others that are in common use for doing numerical things, complex numbers have a natural place. In Java, that's not the case."

Another problem is the handling of arrays, which the group believes is not as convenient as the method used in other

languages. "Java doesn't prescribe how the data gets laid out in memory," said Dongarra. "You have no guarantee that columns or rows of that array will be contiguous. That has some impact in terms of performance for the underlying program." Dongarra noted that the problem rears its head most notably with two-dimensional arrays.

But the most complex problem, and the one Java Grande considers the most significant, concerns how the Java language specification mandates the handling of floating-point calculations. "The way the Java language standard is written today, Java says something to the effect that you have to get the same results on all platforms," Dongarra said. "That's going to have rather serious consequences if things are left that way."

According to floating-point expert Kahan, "Some hardware has better floating-point capabilities than others. The Intel architecture, with three floating-point formats, is intrinsically a superior numerical architecture, because the third format offers you more range and more precision." That format is also supported in the Motorola 68k, but not by the PowerPC, Kahan said.

"So about 95 percent of the hardware on desktops has this stuff, and Java won't let you use it," Kahan continued. "In fact, Java legislates against it. It says in effect that those machines will be crippled, not only in their accuracy but in their speed."

According to Kahan, Java supports two floating-point formats, called floats and doubles. However, he claimed that Java defines the semantics of the floating-point formats so rigorously that there is no way for Java to use the third, extended-precision, floating-point format.

"Even if the hardware has that third floating-point format, it may have other characteristics which Java legislates against and which force the hardware to run unnecessarily slower," Kahan charged. He added that he believes the language works this way because its designers were most familiar with the way Sun's Sparc architecture attacked floating-point processing. As a result, he sees Java as more compatible with RISC architectures such as Alpha and PA-RISC, whose semantics are more in tune with Sparc.

Boiling down the argument to its essence, the critics of the Java spec are really saying today's microprocessors can

do much better than plain-vanilla floating-point. For example, Intel's architecture uses an 80-bit binary internal representation to store floating-point numbers. "The way many processors are made today, they give more precision than we deserve in some sense," Dongarra explained. "But in Java you wouldn't be allowed to do that if we adhere to the standard. That's going to have an impact on things like Merced."

In addition, Dongarra noted that the way floating-point is specified in Java affects not only precision but also performance. "On chips like the RS/6000 and Merced, you can actually do a multiply and an addition in the same time you could do just one multiplication," he said. "So if [the spec] forces the instruction set to issue a multiplication and then forces it to do an addition, that would be a factor of two slower in terms of performance."

The issue came to a head earlier this month at the Java Grande meeting in Palo Alto. There, Kahan presented a

paper, "How Java's Floating-Point Hurts Everyone Everywhere," and outlined why he believes the floating-point changes proposed by Java inventor Gosling are flawed.

For its part, Sun has been addressing some of the questions at issue. Gosling has committed to adding support for extended-precision calculations. He discussed the topic in detail in the context of a broader talk, "The Evolution of Numerical Computing in Java," which he delivered at the 1998 ACM Workshop on Java for High-Performance Network Computing, held at Stanford University in March.

"The current Java numerics spec is essentially a direct reference to the IEEE spec," his presentation noted. "It calls for conformance to the core single- and double-precision floating-point formats, which are the only ones precisely defined. The problem with this approach is that there are vague areas on the periphery of the spec that were left out (like rounding, exceptions and extended precision) largely because there is a fair amount of variability from platform to platform in what they actually implement."

Gosling's paper said Sun is amending the Java spec to permit the use of extended precision in intermediate values in expression evaluation.

"This allows, for example, Intel extended registers and PowerPC fused-multiply-add to be employed," he wrote. "This is largely benign, since it only increases accuracy (double roundings may cause occasional slight decreases in accuracy). It does make floating-point behavior non-deterministic, but in real programs this hasn't been a problem."

Reached by EE Times, Gosling characterized the extended-precision proposal as "just a slight loosening of the spec to allow the X86 floating-point model to be used more efficiently. The broader proposal I was working on, that I gave a presentation on at the ACM conference, is essentially on hold, mostly because there's too much else to do."

As for critics who claim that floating-point questions are of minor importance, Kahan of Berkeley has a response.

"The Java Grande group is like a sliver under the thumbnail of the Java community," he said. "The users of Java are going to be people who have no experience with floating-point computation, except for some isolated event. It's these people who will find that the Java language has a much larger capture cross-section for error than they ever imagined. It needn't be that way. That propensity for inducing people to do things badly is because of the ignorance that went into [Java's] design, not because floating-point is such a dark art."

Nevertheless, Kahan admits that "it is true that the market perception does not accord high priority to floating-point issues."

Moving forward, Java Grande's two major working groups-Numerics and Libraries, and Parallel/Distributed Computing-are preparing reports to be submitted to the entire membership and then to Sun.

According to Fox of the Java Grande Forum, who is also a professor of physics and computer science at Syracuse University, the next major milestone will come in November when the forum holds an open discussion at the Supercomputing '98 conference in Orlando, Fla.

"Our goal is to try to enhance Java so that it's a [more] effective programming language," he said.

A future leg of the forum's efforts revolves around reference libraries. This work isn't something Sun would be asked to provide. Rather, the forum members are seeking to define standardized interfaces to technical software libraries, as well as reference implementations of those libraries.

The libraries would implement functions such as fast Fourier transforms and other engineering-oriented subroutines. The broad goal is to provide a way to achieve standardized, reproducible calculations across different computing platforms and operating systems.

The Java Grande Forum also hopes to spur the development of an application benchmark suite with kernels and with what the group called "more substantial entries."

Finally, the forum is discussing a "Java framework for computing." This is billed as a set of interfaces to support the ability to run any given program on many different computers with a single client interface. The group is also advocating a study of the scaling of the Java Virtual Machine to large applications.