Forté Software licenses Java, but voices concern over the language’s future
David Taber is afraid he has seen Java’s future. He says it looks a lot like Unix’s past.
Taber is senior vice president of marketing at Forté Software Inc., an Oakland, CA, pioneer in distributed application environments. His company has recently licensed Sun’s Java development tools and is Java-enabling its application server and associated tool suite to allow developers to better build large, distributed Java apps.
As a result of Forté’s agreement with Sun, Taber has developed a definite interest in Java portability. As he sees it, many of the big players in the Java industry are introducing incompatibilities into the Java environment in the name of increasing performance, and as a result they may be unwittingly pushing Java to follow in Unix’s footsteps.
“There’s a disturbing trend among many of our colleagues in the business,” Taber says. “A lot of them are licensing Java and then going off and reimplementing critical components from the ground up. They’ll have proprietary JVMs, class libraries, and such. They might pass all the tests but they will yield incompatibilities. They’ll work for small applications but when you get to big ones, these things will step all over each other. This has the danger of being Unix all over again.”
“If you look at the [days of the] flowering of Unix there were about 30 different versions of Unix out there at one point,” he says. “They were all supposed to be the same, but you had to do a port to move software from one to the other.” The days of Unix’s flowering are past, in large part because there were so many versions of Unix and only one version of Microsoft Windows NT.
According to Taber, perhaps as many as half the Java licensees are going the proprietary route, including many of the major ones. “Oracle, IBM, Sybase, Informix, and Gemstone all have their own JVMs,” Taber says. “There’s all kinds of rhetoric about more reliability or better performance, but over the years this kind of variation never plays out well.”
The problem tends to get progressively worse, Taber points out, because the software tends to diverge even further in succeeding editions. After a few years and three or four releases, the incompatibilities tend to be obvious to everyone.
This dilemma is of particular concern to Forte because the Forte development environment is used to build large, distributed applications. That is one of the reasons Forte has licensed its Java virtual machine and other parts of its environment from Sun and intends to use them unchanged. This approach is noble, but comes at a price: if JavaBeans and applets from other sources won’t work with its version of Java, the Java-enabled version of the Forte development environment will have trouble living up to the language’s write-once, run-anywhere promise.
Where this really shows up, Taber says, is in large, complex projects that have to scale. “In high-end distributed computing, this is going to be critical because people want to be able to use a standard language, like Java, and know it can scale up to an arbitrary number of machines with an arbitrary number of users,” Taber says. And they’ll want to know they can do this without a hitch. “These kinds of minor inconsistencies become critical choke points on applications like this.”
According to some analysts and observers, Taber is right. They say the process is inevitable and has happened repeatedly in the history of software development cycles. However, not everyone is convinced it will be as much of a problem as Taber believes it will.
“Every time I hear ‘write-once, run-anywhere,’ I cringe,” says John Rhymer, president of Upstream Consulting, a software consultancy based in Emeryville, CA. “For most people, unless you’re extremely disciplined as a developer and you avoid all extensions and potential extensions, it will be ‘write-once, debug-everywhere.’”
“The way I’ve always written about this is to assume there would be differences in the Java platforms available to the customers,” Rhymer says. “It’s worth everything to compete on performance, reliability, and functional richness, and you do that through the platform.”
The inevitable result is that many, if not most, of those offering Java-enabled products tweak their implementation in some way. Most commonly they extend the feature set by adding to the language, or the libraries, or the APIs. The result may be faster and it may be easier to use, but it isn’t identical.
Does this imperil the whole Java philosophy? The consensus seems to be that it doesn’t. Unlike Unix, the Java language is backed by a strong specification, and it has a powerful enforcer, Sun, to make sure anyone who sells something as “Java” adheres to that specification.
“The language specification itself is really tight,” Rhymer notes, adding that Microsoft is the only company that has messed with the semantics of the language.
“I don’t believe this variation is going to kill off Java,” Rhymer says. “I think it’s inevitable because there are such diverse requirements out there and vendors will compete.”
“I agree [Microsoft’s implementation is] an issue, but I’m not sure I see things degenerated to [such a great] extent.” says Mike Gilpin, vice president of the Giga Information Group, a Norwell, MA, consulting and market research company.
“I think the differences you see among the other [non-Microsoft] implementations aren’t so much the result of intentional efforts to create separate standards,” says Gilpin. Another issue, Gilpin says, is timing. Even companies that intend to be compatible can become incompatible because they use different versions of the software.
As the Java environment settles down, the differences among versions will become well known and documented. Savvy Java programmers will know where to look for potential incompatibilities and how to fix them. In fact, we’ll probably have software to convert Java from one implementation to another.
Instead of Unix, Gilpin suggests an alternate model for Java’s future: SQL. “In SQL not every implementation was identical, but they were close enough that the market became dynamic. I think there’s an opportunity for an even bigger market to grow up around standards like Enterprise JavaBeans.”
