Despite getting a judge in its landmark case against Microsoft to grant a “must carry” order that requires the Redmond company to include Java in the standard Windows XP package, Sun’s fortunes have begun to falter. First, the Court of Appeals issued a stay of the “must carry” order until it could determine if the lower court had the right to issue it, based on the fact that the judge in the Microsoft-DOJ settlement specifically ruled out the “must carry” option in her final opinion.

Now one of Sun’s own engineers has gone public with concerns about Sun’s Java platform and the future of its Solaris operating system. This engineer’s views reflect the wider concern of many CIOs who’ve bet their careers on Java over the last few years. Let’s look at some of the issues raised during Sun’s internal debates over the future of Java.

Problems with Java
The Inquirer, a Web site dedicated to promoting Linux, recently released an article, "Sun’s own engineers find Java ‘impractical,'" in which a Sun insider expressed concern about the current state of Java and Solaris. He also wondered whether there’s a basis for Sun’s current suit against Microsoft. The engineer said, “It strikes me as hypocritical for Sun to blame Microsoft for any failure of the Java platform when Sun's own engineers find developing common software applications in Java impractical.” These technical issues, he claimed, "prevent general acceptance of Java for production software within Sun." If Sun won’t use its own product for developing production software, why should it expect the business community to buy into its vision?

To be fair, many of his concerns are not with Java specifically, but its implementation on Solaris. The Java footprint on Solaris is “rather large” and even though there are significant developer productivity advantages to using Java (as compared to C and C++), “its implementation on Solaris makes it difficult to deliver reliable applications.” I find it interesting that the engineer would question the reliability of applications developed on a UNIX platform given the current campaign by Scott McNealy to paint solutions deployed on Solaris to be reliable, while questioning the viability of applications deployed on Microsoft platforms. It’s pretty clear from this insider’s comment that Scott has been on the road too long and should probably get back to the labs and fix his own problems.

Unfortunately for Sun, many of the problems aren’t Sun-specific, but problems with any implementation of Java. For example, the engineer pointed out that since every Java program depends on the underlying Java Runtime Environment (JRE) and Sun hasn’t built specific release management into the JRE, an installation of a new version of the JRE can break existing applications. With Sun issuing JRE updates every four or five months, it’s very easy to destroy existing packages that can’t be downgraded to the previous version. And, according to the engineer, the notion of “Java everywhere” is questionable given “the size of the JRE, which can in some cases hog huge amounts of memory. That needs to be fixed by as much as 80 percent or so.”

.NET "fixes" for Java issues
Before delivering its virtual machine platform, Microsoft made sure that many of these issues were addressed. Microsoft had also spent years dealing with its own problems with versioning (a.k.a. "DLL Hell”) and performance issues with its communications protocols (most notably DCOM).

Microsoft is going through the first test of its “side by side” deployment scenarios with the imminent release of version 1.1 of the .NET Framework, due in the first half of 2003. I’ve spoken with many companies that are testing the new version of the .NET Framework (and have done some testing on my own) and haven’t had any compatibility problems with software products using different versions of the .NET Framework on the same system.

The move to Web services standards as the platform for cross machine object utilization has put Microsoft in the center of the network computing universe—a space that Sun once tried to claim. The next release of Java will include native support for Web services, but Sun still insists on trying to support a different set of standards than those agreed on by the rest of the computing world (including IBM, BEA, Novell, Oracle, and others). Sun’s efforts to recoup its investment in Java by making it more proprietary as it bolts it onto Solaris is an obvious attempt to replicate the Microsoft model while appearing to be open.

External engineers see the same problems
In fact, Sun’s problems aren’t going unnoticed by the technical teams of some of its stalwart customers, and some of them are defecting. As reported by news.com, one of Sun’s marquee clients, Pixar, announced that it’s taking out Solaris (called “Slowaris” by the Inquirer) and replacing it with Intel Xeon processors and Linux.

Customers are beginning to recognize that Sun can’t fight three battles at once—Solaris vs. Linux, Java vs. .NET, and Microsoft in court—without it affecting its ability to compete in the marketplace. CIOs with significant investments in Solaris and Java need to begin looking at their Linux and .NET options in case these problems force Sun into a supernova.