Letters to the Editor

Is it hot in here? We feel like we've jumped from the frying pan to the fire this month, as readers blast our coverage of several important (and admittedly controversial) issues. As a general principle, we stand by our writers tooth and nail; but that doesn't mean they -- and we -- don't benefit from a healthy argument

"The impact of Java standardization" by Bill Day

Read

Why charge for standards?

Bill,

I was disappointed that you failed to mention electronic access to the current drafts of the standards.

Hopefully we aren't about to repeat the C++ experience.

Gary Johnson

I looked long and hard for such online specs, but unfortunately, the ISO charges for access to its standards. This is OK, (not great, but bearable) for many companies and government organizations, but it's difficult for individuals, small research groups, and small companies. You can access the "Why charge for standards?" statement from ANSI (the body that represents the United States in the ISO) at http://www.ansi.org/why_chrg.html. I don't agree with all of their reasoning, but at least they've attempted to explain it. They also offer a section on electronic dissemination. Once drafts of the Java language, virtual machine, and API specs are ready, I hope that JavaSoft will provide online versions on their "Java Standardization" Web site, at http://www.javasoft.com/aboutJava/standardization/index.html. If by "C++ experience" you refer to the many years it took for the C++ standard to be ratified, yes, we should all hope (and insist) that Java standards be submitted and approved more quickly. Luckily for developers, it's in Sun's best interests to standardize the language, VM, and core APIs as quickly as possible so as to preempt Microsoft's ability to co-opt the Java Platform. Because of this, I expect we will see these basic parts of Java standardized within a matter of months. Bill Day

Monopoly: Not just for Microsoft

It seems that you feel that only one company is interested in fragmenting Java -- Microsoft. Right now, that may be true, but for how long? With time, Sun will increase its hold on Internet/intranet development (assuming that Java succeeds). Eventually, companies will seek to topple the Sun/Java monopoly just as they seek, now, to topple Microsoft/Windows.

Maybe a non-profit organization should have been approved as the PAS instead of Sun.

Urjit Dave

I agree that there are other companies working to fragment Java, or that there will be with time. But Microsoft is the only one that is presently big enough, influential enough, and interested enough to succeed. It is also the company that Sun has singled out, which is why I chose to compare and contrast Sun's strategies against Microsoft's. Even with a non-profit standard, companies will add extension APIs and find other ways to fragment Java. The issue cuts to the core of proprietary versus open standards; a debate that has raged in the engineering community for some time. We'll see which philosophy prevails for Java. As developers, we must understand the strengths and weaknesses of both philosophies, and make concessions only as absolute necessity requires it.

Speculating on a Windows-only world...

Standardization of the Java APIs is important even to developers who don't care about OS independence. Even if we assume that only the Windows OS is important, we have to remember that there are several browsers that run on Windows. It is critical for use of Java on the Internet that all Java-enabled browsers have the same set of APIs available. Otherwise, users will be stuck downloading huge sets of classes that browsers ought to provide.

Dave Neuendorf

Excellent insight! It is true that even in a Windows-only world, we would have different browsers (Netscape and Internet Explorer, at the least) and different flavors of Windows (3.1, 95, NT). As a matter of fact, browser-based Java runtimes are probably the least compliant because of their differing security models and target platforms. Standardization can definitely help here, if implemented well.

Microsoft: Loathsome, but understandable

The C language would be relegated to OS and low-level development without the guaranteed availability of certain standard functions. Without standardized APIs, Java would be relegated to a mere curiosity.

Microsoft's position, while loathsome, is understandable. As stated in the article, Java does threaten its stranglehold.

Stephen Paulsen

Your comparison of the development of and potential success of Java to that of C is directly on point: For Java as a whole to succeed, the core APIs must be a part of the standard. Microsoft knows this and feels that it must find ways to resist the standardization of these APIs. Isn't is interesting that both sides of this discussion (Sun and its allies as well as Microsoft) have legitimate interests behind their positions? I think everyone (including working developers) is better off understanding not just the technological challenges, but also, more importantly, the business decisions driving the evolution and standardization of Java.

Industry domination: S.O.P.

You are far too Sun biased and assume incorrectly that Sun has better motives for their actions than Microsoft. Is Microsoft trying to dominate the industry? Yes, and so is IBM and, in particular, Sun. The only difference is that Microsoft is successful.

I love what JavaSoft has done in most cases, however, Microsoft's extensions to Java have corrected many ill-conceived extension APIs. Take the example of RMI, which can talk to Java apps and no others. This means it can talk to about 5% of the apps available today. Compare this to Microsoft's DCOM, which can talk to 85%. Who is trying to be proprietary here?

Bill Hepworth

You're right, no company in this business would turn down the opportunity to dominate the industry. I maintain, however, that given their statements that they would not turn Java over to an independent body, and given their willingness to address concerns filed in the first round of PAS approval voting, Sun seems to be the only workable solution for the time being. Without any sort of Java standard, Microsoft would probably succeed in its attempts to fracture Java. I honestly believe this would be bad for Java developers, as portability is one of Java's key benefits. RMI is an interesting example of how Sun's partnerships in the industry have resulted in strategy changes for JavaSoft's development. Initially, RMI was to remain a Java-only technology, with no ties to CORBA. This would have left RMI extremely proprietary, in the sense that only Java VMs would have been able to use RMI, as you point out. Due to partner complaints and developer requests, however, JavaSoft has stated that they will re-architect RMI for use with IIOP. RMI will be able to interoperate with CORBA, and thus with the vast majority of services on the emerging "object Web." I believe RMI to be a sterling example of how Sun's previously constructed Java API review and comment process can work. Microsoft still resists developer and ISV requests to tie DCOM fully into CORBA.

"Results of first-ever JVM server benchmark revealed" by John Neffenger

Read

Kaffe for free

I see that Linux is at the end of the list. Grab a browser and point it here: http://www.kaffe.org for a free Java virtual machine.

Dean James-Everett

We were actually quite hopeful that Kaffe would come through with a great Java virtual machine for Java server applications. I have tried it myself on Solaris SPARC, Solaris Intel, FreeBSD, BSD/OS, Windows, and Linux, all with no luck in getting over a dozen concurrent connections. I would love to see a more recent version of Kaffe run VolanoMark, but I'll leave that to those with more persistence. John Neffenger

Something strange...

Something strange from IBM:

The OS/2 release leads performance on Intel platforms. CaffeineMark 3.0 benchmark results show Java applications run 7% faster on OS/2 Warp 4 than on Windows NT with Internet Explorer 4.0.

I know that "benchmark" is worth no more than the nine letters that make up the word, but this is a day and night difference from your results.

What's missing?

Kim Cheung

In two words, sockets and threads. We wrote VolanoMark precisely because the CaffeineMark applet gives no indication of the Java virtual machine's ability to handle a large number of network socket connections and the threads which manage them.

Use of Intel boxes invalidates benchmarks?

I felt that the server benchmarks presented were not a true indication of the relative performance of the JVM on Solaris. You used Intel boxes, and we all know how badly Solaris performs on Intel boxes compared to SPARC.

I'm not saying that Java on SPARC running Solaris offers better performance than Java on Intel running WinNT. I just don't think the benchmarks offer a true indication of the relative performance between WinNT and Solaris. The title, therefore, is misleading. How many people use Solaris on Intel as a server platform? The title should have been: "Results of first-ever JVM server benchmark on Intel revealed."

Finally, when running benchmarks, it is not important to have the OSs running on the same hardware. That's not how it works in the real world. One should use machines configurations that cost about the same amount of money. This gives a true indication of cost vs. performance, which is what most people want to know.

Jay Jayaprasad

When you're directly comparing software implementations, it only confuses the issue to switch the hardware underneath. We tested the speed of the Java virtual machine and operating system from each vendor. The only way to do a fair comparison was to use common hardware on the bottom and a common test program on top. At Volano, we use Solaris 2.6 Intel Edition, as do many of our customers. I'd say the split is about fifty-fifty between SPARC and Intel for our customers running Internet servers. If no test of Solaris is fair unless it's on a SPARC, why does Sun even offer the product? How much closer to identical cost can you get than running the OSs on identical hardware? I think you would have a hard time finding a SPARC machine from Sun for the price we paid for our new Intel boxes. Our customers know that if they buy Intel they can run Windows NT, OS/2 Warp, Linux, Solaris, SCO, FreeBSD, BSD/OS, and dozens of other operating systems, many of which offer a Java virtual machine. More and more, we find they've got a few Intel boxes lying around and come to us to find out which operating system they should use to run our VolanoChat servers.

100% Pure Java compiled bias?

Just because it's 100% Pure Java doesn't necessarily mean it's unbiased as a benchmark; it only ensures that it is supposed to be portable across all (correct) implementations of Java. This can be viewed analogous to a non-Java programming language, say C or C++. I can write a 100% portable C/C++ benchmark, run it on the same operating system, yet depending on the compiler used, the performance may differ.

Andy Kahn

Dear Andy, The analogy to compiled C or C++ code doesn't work. We used the same compiler for all tests (JavaSoft's JDK 1.1.4 compiler). In fact, we compiled only once and used the same exact class files on all machines. Same exact hardware, same exact 100% Pure Java compiled bytecodes, with a different operating system and Java virtual machine sandwiched between the two. The vendor who can get the bytecodes to run on the hardware the fastest is the winner. How could that be biased?

And, what's more...

I'm surprised that you didn't mention the Symantec or Borland JITs and how they compared to the Microsoft 2.0 SDK.

Jay Lorenzo

We ran the Java virtual machines that our customers run. They almost always run the Java support that is made available for free by the vendor of the OS they're using. I'm hoping that some reader will run VolanoMark on Symantec's or Borland's Java virtual machines and post the scores to JavaWorld at: http://www.javaworld.com/javaworld/jw-12-1997/jw-12-submit.volano.html

Java vs. Java -- inaccurate comparison

Did you use the Symantec JIT on NT with JavaSoft's JDK? If not, I can't see how your article and results are truly accurate. In fact, they are very misleading.

Steve Lewallen

I assume you're referring to the "Java vs. Java" comparison. The purpose of that chart is precisely to show what the addition of a JIT compiler and native threads to JavaSoft's reference release can do for Java server-side performance. By JavaSoft's reference release, I mean the non-optimized, no JIT, perhaps no native thread version of the JDK. I don't think the article is misleading at all, although I will ask JavaWorld to reiterate the point that only the first chart is meant to declare a "winner." All of the other charts are simply to show what great performance improvements operating system vendors have made in the last year, and what a JIT and native threads can do over JavaSoft's non-optimized reference release. JavaSoft only recently got into the performance game, with their "performance runtime" releases. There are literally dozens of other licensees that take JavaSoft's reference release and enhance it just for the Windows NT platform, including JavaSoft themselves, Microsoft, symantec, Kaffe, Softway Pty. Ltd., Borland, and SuperCede, to name a few. You suggest I should have chosen to compare JavaSoft with JavaSoft. I chose to compare the reference release with the one that is or will be included with the operating system itself -- Microsoft for Windows NT, SunSoft for Solaris, Blackdown for Red Hat Linux, and IBM for OS/2. If you're interested in publishing the results of any of the 113 Java licensees excluded from the article, I encourage you to run VolanoMark and post your own results to: http://www.javaworld.com/javaworld/jw-12-1997/jw-12-submit.volano.html

Point, counterpoint

1 2 Page 1
Page 1 of 2